To provide any comments on this solution,
click here.
Add your comment under an existing answer ("add comment" link) instead of a new answer. Thank you !
This article suggests a way to manage accesses given to users in Octopus.
It covers the following sections :
- How to keep a record of all accesses through Octopus;
- How coordinate access creation.
EditAn Access Management via Octopus CMDB
Accesses can be managed into the Octopus CMDB.
To do so, create first a
CI type "Access". Then, for each access type (Octopus - Administrator, for instance), create a CI.
Example of a CI Access list :
- Name : unique identifier of access type
- Main Contact : person responsible of access creation. The owner of the main system to which the access is associated could be defined in Information System CI
- Status : In Operation, Retired (you can add more status)
- Criticality : if necessary
When you grant an access to a user, you have to add it in user list of CI Access. Then, you can obtain rapidly a list of user for this access, and also all the accesses granted to a specific user.
Example of user's accesses :
The association of a access to a user should be done at a SR completion or when a access creation task is executed within a change. Also, a SR or a change should be associated to CI Access. In this way, you will be able to trace all requests of access executed for a specific access.
Other configuration suggestions :
Creation of a CI type « Access Profile » grouping several accesses
Useful if you normally grant several accesses at the same time.
Instead of associating an access to a user, you associate the CI Type "Access Profile".
Example of an access profile: "Visiting Nurse".
Association of CI « Access » (and access profile) to Information System
If your information systems are documented in Octopus, it would be interesting to associate accesses related to an information system.
EditAccess Request Management
In Octopus, there are two (2) sources to make a request for access :
- Service Request (SR) issued by a user or a manager ;
- Task(s) of access creation within a project (release of a new system, by instance).
Here is a scenario showing how could be treated a request for access :
- A user submits, through the Web Self-Service interface, a request for access for an employee.
- Depending on the configuration of the SR type and its tasks, a SR can be sent automatically by email to a group (and/or an assignee) when created - it is good use to give the responsibility of SR management to the Service Center. Service Center is responsible to follow the SR, and to verify task assignment to proper group (or assignee) responsible of task execution. The SR is also associated to the CI Access to retrace granted accesses.
- The assignee execute the task(s) assigned to him and create the access(es).
- The assignee change the task status to "Completed" and make sure to establish a relationship between the access and the user.
- Service Center change the SR status to "Resolved".
Note: This scenario is only an example and the configuration can be defined differently, according to the internal working methods applied in your organization. The most important is making sure that the process is known and followed by all to assure the integrity of accesses that have been granted.
EditAccess Management for ABC system is done by someone part of another department, how can we integrate this person in the SR execution process?
- Create an Octopus account to this user - you will be able to assign him (her) a SR.
- Limit the Octopus permissions to Request consultation only (uncheck "Web application for technicians \ See opened incidents/SR") and limit his (her) capacity to change the SR status (check "Incidents/SRs \ Modify an incident"). The user will be able to access through the Web Self-Service interface for technicians, which is very easy to use. ***A special price setting is applied for this type of user.***
Note : For the moment, only Incidents/SR and Events can be accessed with Web Self-Service for technicians; context described above doesn't allow task assignment to this type of user. You must create specific SR.
EditHow do I proceed if the request implies creation of several access executed by different people?
Octopus introduced task management functionality in SRs. Each type of SR can be configured with specific configurable tasks containing the following characteristics:
- A task can be concurrent (executed at the same time of another) or subsequent (fired after another is completed) by identifying dependencies;
- We can define the due date, meaning the time we allocate to a resource to execute a task, or specify a date for the execution
- We can enter instructions for the assignee
- We can specify the group where the task will be assigned (and the assignee as well)
- We can indicate the estimated effort to execute this task
- We can create a "Follow-up" task - this task will be kept opened even if the SR is completed (ex. a stagiaire or consultant for which we have to remove accesses after 3 months).
See video (in French only)
Tasks per type of service request to see how works this functionality.
It is then possible to configure in advance multiple tasks for a SR, instead of creating separate SRs that need to be related.
How do I record a SR if it is for a new user that is not part of Octopus database yet?
In order to link in all time your SRs with beneficiary users, you can create a generic user "IT Service" and change it when the SR is completed (a task could be created for this). This will avoid a requester to be associated to multiple SRs that don't belong to him.
EditHow do I do if an approval is required?
A complete approval process for each type of SR will be integrated to Octopus in 2010.
Actually, when receiving a SR, you could :
- Suspend the SR and select the reason « Waiting For An Authorization » to stop SLA counter.
- Create an activity type "Approval Required" and insert in it an email template asking for an approval. When an approval is required, add an activity to the SR and select the activity template. Use the email functionality to send the activity to the user to obtain his (her) approval.
- Octopus will automatically send the email to the approver.
- When receiving the approval email, the approver will connect to Web Self-Service to add an acceptance (or refusal) message to the SR.