Policy Security Administration (a.k.a "PSA") is Fischer's ABAC authorization engine. This feature is built with the intent to build a hardened authorization and security model to govern all Identities using the Fischer's IGA Suite. This native authorization feature touches all features of the product and provides granularity coupled with dynamic configurations empower IGA Administrators to lock down and govern how their Fischer solution functions in the context of who is allowed to do, see and take action on. On a generic scale, Fischer's PSA security model focuses on governing end users, authoritative users as well as IGA Administrators. As you configure your solution, you will find this feature embedded into all core communications where authorization is required before user interfaces can render what the user is allowed to do.
Fischer's PSA model consists of a "bottom up" approach for construction authorization policies. The following sections will break down what each layer of the configuration is intended to do. To accomplish a successful authorization and governance model, IGA Administrators must be able to fully understand Fischer's Policy Security Administration Feature.
It's important to be aware that authorization policies are evaluated post authentication and prior to presenting any user interface to the end user. This process occurs at the source code level and if you are interested in reviewing what a user was authorized for, you can check the user's Identity Profile, or review the Logs.
Authorization is split into 3 distinct layers.
Delegate Access | |
Governance of access to any defined authorization policy. This is an important layer of oversight when building out your authorization model. In order to properly segregate duties and provide a mutually exclusive governance model, for each authorization policy created to obtain access to Administrative or Self-Service features, a corresponding Delegate role should be created to oversee and govern membership to all authorization policies of the same type. Without a delegate policy in place, there is no oversight in place to govern your administrative authorization policies. | |
Admin Access | |
Admin Access authorization policies will govern access across the entire product suite. It is important to understand the features and objects associated with a given admin policy to ensure you have an understanding of exactly what access is granted as a result of policy membership. This will be discussed in further detail below. | |
Self-Service Access | |
Membership in self-service authorization policies will govern the features and functionality qualified members are able to utilize within Fischer's Self-Service feature. |
In order to understand the feature, IGA Administrators will need to focus on the following concepts as it relates to deploying an authorized model. Here is a screenshot of the feature within the admin UI. This guide will drill down into the specifics of what each item is responsible for.
Fischer's Policy Security Administration feature takes aim at providing IGA Administrators with granular authorization enforcement options. One important item of note is this feature governs access to all features of the Fischer IGA Suite. It is intended to govern both external (end users) accessing the product's self-service interfaces, as well as administrators themselves. It is a powerful feature and can provide organizations with ultimate control over who is able to perform what set of functionality as well as who has access to different features within the product. This guide will give an overview of the available options and functional components of the feature. There are specific guides that will provide more granular details of each option in the Function menu.
Delegate Authorization
Delegate Authorization provides governance over all other policies as defined within the same category. For example, Fischer provides a Connected System Administration authorization policy that allows for members of the policy to take administrative action (add/mod/delete) all features associated with Connected Systems however Connected System Administrators cannot modify membership of the Connected System Administration authorization policy, only members of the Delegate Authorization policy associated with the Connected System Administration policy can modify membership. Note that the master administrator account has global privileges and can perform any task in the administration user interface. It is best to minimize the amount of master administrators are created, and instead focus on building out feature administrators that can focus on their area of responsibility within their realm of authority. It is important to ensure that for each Admin or Self-Service Access authorization policy that is created, that a corresponding Delegate policy is also created. Furthermore it is important that membership to the Delegate policy be mutually exclusive to any policy it may govern. An organization should never allow a member of an administrative or self-service authorization policy to also be a member of the governing Delegate policy.
Delegate Authorization members will be able to manage membership to associated policies. For all Delegate members (in the context of the feature they are a delegate for) will see a screen similar to the screen below.
The above example is Compliance Delegation (which provides governance over members of the Compliance feature). The Compliance Delegation feature offers qualified members with a view into the authorization policies themselves. This is a powerful feature to lock down and govern the actual authorization policies themselves, specifically controlling membership so that organization's can control which administrators or third party entities are able to interact with Fischer's compliance feature set. Again, it is very important to provide a clean separation between Compliance and the rest of the administrative processes. A Compliance Delegate's view looks like this:
Segmenting the ability to view and manage the compliance authorization policies is a significant feature that provides organizations with the ability to provide access to independent entities, when necessary to expand or lock down the authorization policies. Compliance delegates can control compliance within an organization or externally. This feature can provide a significant level of oversight and governance that is abstracted from an organization's core administrators. Because IGA Administrators must be monitored as well if an organization truly wants to remain in control of their organization. As you drill down into the Compliance Delegation feature, the level of control is perfect as it relates to this type of persona operating within an organization's Identity ecosystem. By click on "Compliance Administration", you can see that Compliance Delegates have the ability to administrate membership. This capability provides separation of authority as it should when speaking on a relevant governance model:
The actions that a member of a delegate policy can take are limited for the System (i.e. out of the box) authorization policies. Let's explain the screenshot above. You'll notice that Delegates only have the ability to view the components of a given authorization policy. By default, Delegates are authorized to take the following actions:
- Add static members to the authorization policies governed by the Delegate
- Append the governed administration policies to include other Object Categories, HOWEVER FISCHER DOES NOT RECOMMEND AMENDING A DEFAULT AUTHORIZATION POLICY. Refer to the Implementing Authorization Guide for details on how to build out a custom authorization model to meet your organization's specific needs.
The above example of the access provided to Delegates is the same across all Delegate Authorization policies. We will not show samples of every Delegate Authorization policy as they all provide the same level of capabilities across all features where a Delegate policy is defined.
Administrator Authorization
Administration Authorization provides organizations with the ability to govern which administrators are able to perform administrative actions across Fischer's product suite. The ability to control how administrators are able to interact with the system is extremely important and should be a part of any IGA Program. Locking down administrators to only operate within their realm of authority is an important pillar of security and it can help to decrease an organization's risk profile. While there are many features within Fischer's IGA Suite, understanding and properly implementing the authorization layer should be considered one of the most significant aspects of implementations and an organization's overall IGA Program initiatives.
Let's start by showing you how to add a member to an authorization (PSA) policy. You must have master administration or delegate administration rights to add members to authorization policies. Administrators will access the "Policy" tab within the admin UI:
Next, you will select a policy you want to add an administrator to. For this example, we will use the Approvals Administration Authorization Policy. Once you select the policy, your screen will look like this:
You will now click on "View Members" and your view will change to the following:
Next you will click "Add Member" and you will be presented with a list of Identities to choose from:
You can select one or more members to add to the authorization policy. For this example, we will click on one user and then click "Select"
You'll see the message providing you instructions. What you will need to do next is click "Back" as instructed:
The last step is to click "Update" and the member will be added to the policy. For each authorization policy, please refer to the separate article explaining the permissions granted for each administrative role.
Approvals Sub-Administration |
The Approvals Sub-Administration feature provides administrators with access to the following (each hyperlinked item will take you to the corresponding feature guide for more details):
Feature Guide Refer to the Approvals Feature Guide for details regarding the list of features above. |
||||||||||
Category Administration |
This product feature is explicitly exposed to define Object Categories. Specifically to create custom Object Categories. Administrators who only have access to this feature will see the following once authenticated to the admin ui:
|
||||||||||
Compliance Administration |
The Compliance Administration feature provides IGA Administrators with the ability to offer a compliance-only view. This feature can be very useful and of significance to organizations that require strict compliance per regulatory and/or legal guidelines. The feature of Compliance Administration provides an organization with the ability to create segregation of duties and only allow (by authorization policy) employees, or third party entities with access to Fischer's Compliance feature. It is often times extremely important to offer this separation and can serve as a very powerful tool to create and maintain governance and control over security. When an administrator is granted the Compliance Administration feature only, their view will look like this:
Feature Guide Refer to the Compliance Feature Guide for more details. |
||||||||||
Compliance User |
Administrators authorized to use the Compliance User feature will obtain a significantly lower level of access than Compliance Administrators. Compliance Users can be users such as Compliance Officers or Auditors that need to be able to view any exceptions thrown as a result of executing a Compliance Assessment as well as Viewing all product reports. A Compliance User's view would look like this:
What's the Difference? Note that membership to the Compliance Administration authorization policy allows administrators to build and execute Compliance assessments. While membership to the Compliance User authorization policy will grand read only access to the results of the assessment and as well as read only access to all system reports.
Feature Guide Refer to the Compliance Feature Guide for more details. |
||||||||||
Connected System Delegation |
The Connected System Delegation authorization role enables a qualified administrator with the ability to manage the Connected System(s) policies.
|
||||||||||
Connected System Administration |
Connected System Administrators are authorized to manage all configurations as it relates to each end point (e.g. Connector). IGA Administrators can authorize SMEs to manage all aspects of their integrated connectors within Fischer.
|
||||||||||
Federation Administration | |||||||||||
Federation User | |||||||||||
Monitor Administration | |||||||||||
Provisioning Policy Administration |
Provisioning Policy Administration Authorization provides Administrators with access to the following components (each hyperlinked item will take you to the corresponding feature guide for more details):
|
||||||||||
Provisioning Policy Sub-Administration |
Provisioning Policy Sub Administrators have a sub set of access within Fischer's RBAC provisioning feature set.
What's the Difference? You'll notice that Resources, Policy Sets (SoD) are the two features removed from the sub-administration policy. The intent here is to provide for a hierarchy as it relates to administrating provisioning policies. The two items removed from the sub-administration policy should be granted only to authorized IGA Administrators that are allowed to manipulate access in the context of each policy. Hence the separate authorization policy for provisioning.
Provisioning Policy Administration Authorization provides Administrators with access to the following components (each hyperlinked item will take you to the corresponding feature guide for more details):
|
||||||||||
Provisioning Policy User |
Members of the Provisioning Policy User authorization policy have significantly less access to Fischer's RBAC provisioning feature set.
Authorized Admin Tabs:
Functionality is Limited You'll quickly see that members of this authorization policy only have access to the Prov Policy tab in the administration user interface, as well as a decreased level of permissions. Members of this policy are allowed to view the contents of the policy but are not able to make any changes to the configuration (i.e. the qualification criteria defined within the policy itself) other than the following:
Furthermore, members of this authorization policy have the ability to Add, Remove, View and Remove all members of the policy. |
||||||||||
Report Administration |
Members of the Report Administration authorization policy are limited to Fischer's reporting functionality only. Report Admins are able to view all available reports as well as "Manage Reports".
Authorized Admin Tabs:
|
||||||||||
Report User |
Members of the Report User authorization policy are limited to Fischer's reporting functionality only. Report Users are able to view all available reports.
Authorized Admin Tabs: |
||||||||||
Security Administration |
Members of the Security Administration authorization policy are granted master administrative capabilities to define an organization's authorization model. Organization's should reserve this role for Compliance, Information Security and other like job functions. Organization's should define who your security administrators early on in the deployment of Fischer and begin to learn how Fischer's authorization engine functions, the associated features and governance options available. This effort can run in parallel to the actual implementation of the Fischer product for other features such as password management, provisioning, etc.
|
||||||||||
Security Sub-Administration |
The Security Sub-Administration authorization policy aligns closely with the Security Administrator membership. The only difference is that members of the Security Sub-Administration policy are unable to interact with the object categories feature. This feature is used to categorize (i.e. enforce) security within the context of the features associated with the defined category. By removing access to this feature from Sub Administrators, they must work with the defined authorization policies as is and they cannot make adjustments to what the authorization policy explicitly provides in terms of functionality.
|
||||||||||
Security User |
The Security User authorization policy further limits access to Fischer's authorization feature set. Security User members are only authorized to perform the following functions:
Cannot Remove Self Note that members of this authorization policy are able to add/remove administrators from the policy however they are unable to take action (i.e. remove themselves from the policy) Sub-Administrators and Administrators are the only users able to do this. |
||||||||||
Self-Service Administration |
The Self-Service Administration authorization policy provides administrators with the ability to manage all aspects of Fischer's Self-Service feature set, including the necessary administrative functionality to manage Self-Service.
|
||||||||||
Server Configuration Administration |
The Server Configuration Administration authorization policy should be leveraged by Infrastructure and IGA Program Administrators as it provides access to global product configurations.
|
||||||||||
SPML Administration |
The SPML Administration authorization policy provides a single function that allows members to view all SPML events that flow through the system. When an SPML Administrator authenticates to the administration user interface, they will see the following screen:
|
||||||||||
Trigger Administration |
Trigger Administration focuses on integration with end points. This role is not often used by itself, however it is available. This role would be best reserved for Infrastructure personnel so they can focus on ensuring the solution is functioning and automated processes are running, and the solution is running efficiently.
Authorized Admin Tabs and feature access:
|
||||||||||
User Administration |
The User Administration authorization policy provides for organization's to allow select IGA Administrators to administrate users from the Admin UI as well view the workflow instances, and all associated end-user events.
Authorized Admin Tabs and feature access:
|
||||||||||
User Group Administration |
User Group Administration authorization allows qualified members to administrate Fischer's User Group Feature.
|
||||||||||
Workflow Administration |
The Workflow Administration authorization allows qualified members to administrate all deployed workflows within the context of the the features below:
|