Policy Security Administration (Overview)

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.

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:

1. Add static members to the authorization policies governed by the Delegate
2. 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.