IGA Design Requirements
| This page is a stub, it is a work in progress. |
This document collects requirements for IGA processes and IGA design that should be fulfilled by the design.
Requirements for Role engineering and maintenance process
-
Balance risk together with processing speed and management costs
-
Flexible approval process (different approval schemes for different types of users)
-
Split tasks that are managed via GUI and via Idea
-
Role will define all components needed to obtain required access
-
Design of the roles must support parameters (parametrization)
Requirements for role request process
Main requirements for designing of the Role request process:
-
Throughput and speed of the process
-
Manageability of the process and visibility
-
end user can easily see all his requests
-
end user can easily see all requests for him
-
IDM administrator can easily see failed requests
-
IDM administrator can easily see long request
-
-
Process should be easy to understand.
-
Exceptions in the process are managed ad hoc
-
-
Process is managed by IDM administrator
-
analyze specific request and troubleshoot it
-
-
Process is managed via GUI
-
Balanced notifications - not too many
Requirements for IGA reporting
Reporting must be able to provide data for:
-
managing environment (central visibility - Big picture)
-
management and optimization of the processes
-
answering the IGA question of "Who has access to what and why".
-
Actual state of the access environment:
-
scope of the environment (dashboards with counts):
-
number of users of different types (or organizations)
-
number of applications of different types
-
-
-
Environment dynamics (what is happening, what are the changes)
-
In previous periods
-
-
Must be able to address the question of "Who has access to what and why"
-
Process throughput and speed monitoring:
-
how many requests was created in defined period
-
how many requests from defined period was closed in specific time (e.g. I want to have request closing rate of 95% of the requests within a week)
-
-
Process quality monitoring:
-
request success rate
-
How many request failed
-
-
data for process and environment optimization:
-
which requests are slow to approve
-
which manual tickets are slow to
-
part of automated and manual requests
-
how many manual tickets were generated per each application - identify applications that should be automated
-
-
fast option to select application and see who has access to the application
-
fast option to select user (or set of users - e.g. OU) and see all the roles assigned to the user.
-
nice in the matrix view - to see id there are any discrepancies - that some users have missing or excessive access rights
-
-
why - visibility why each role is assigned to specific user - whether it was by some policy (which policy), or by some request.
| It would be great selling option if we could visualize the data. Visualization of the environment - who has access to what - can be identified. |
Policy reporting - we need to report policies somehow → I don’t know how at this moment.
Requirements for User interface
-
UI must provide means for troubleshooting the processes.
-
Delegated administrators must be able to troubleshoot the process.
-
-
Auditing must provide data in business terminology - and in big picture
-
user’s history - it is not enough that user is displayed only that something was changed on the user in the view.
-
in the view must be identified what field(s) was updated - without need to opening the events - even when we can’t open the user in multiple tabs.
-
-
-
For Role engineering - UI must support easier copying of the role definitions between environments.
Requirements for methodology
-
Naming convention for roles should be designed that user is able easily identify what role he should request.
-
Manage risk of access with controls (using approval, certification) versus speed of the process