Fischer's Framework for IGA

As with all Identity Governance & Administration products.  Each product may talk about or name their features something differently (i.e. their own nomenclature).  Understanding the global concepts in this guide below will help you to understand the Fischer product and nomenclature.  As you progress through the different training guides and documentation it will help you to understand these concepts before continuing.

Connected Systems

Fischer calls all third party integrations with end target systems, "Connected Systems".  This should be understood as the point of integration between Fischer and third party applications.

Workflows

The term "Workflow" is widely used across multiple disciplines.  A workflow within Fischer is considered to be an automated provisioning process or any transaction associated with exporting, transforming and importing data to Connected Systems.  Workflows are spawned from from The Workflow & Connectivity Studio.  This is the sole source for creating a workflow within Fischer.  While some may consider the inclusion of Approvals, etc. as a workflow you can get confused within Fischer if you consider a business workflow in the same context it is referred to within Fischer.  While approvals can be placed inside of an end-to-end business process and workflows can be put into a suspended state until the access associated with the workflow is approved. 

Attributes

Competent attribute management is the foundation of securing the identity. It is the attribute and its corresponding value that ultimately determine the digital identity of an individual (or entity). When you consider the level of accuracy required (if your true goal is the validity of the transaction) you will concede the importance of properly representing the user to proofing, verification and authorization services. When you consider attributes within this context, it becomes clear why Identity Governance & Administration is the epicenter for securing the identity. An "attribute" is a specific item that is associated with a Fischer Identity Profile.  It is also used in the context of Fischer's LDAP integration as the LDAP end points refers to attributes when defined objects within the directory.  On a larger scale, an attribute is born from Object Oriented Programming.

Attribute management is much more than “just a middleware component;” it is identity management at a fundamental level. This fundamental level must not be overlooked as our industry begins discussing the large scale initiatives to create a common “ecosystem” through which cloud identities will travel.

Resources

It is also important to understand that a resource should be treated as an object in and of itself.  The attributes of a resource that are required to be considered completely defined are an Add and Delete workflow, and a Connected System at a minimum.  There are many other attributes of a resource that will be discussed in the subsequent Resource Feature Guide. Resources within Fischer is an abstracted concept that can help to organize and control how access is defined.  Within Fischer, a resource is an entity that is provisioned or de-provisioned to/from an Identity.  Resources are a fundamental pillar of deploying a Fischer IGA solution.  Within Fischer, we call an account (a target system account, not the Identity profile) and an entitlement a resource as we build out solutions.  A resource is a mutually exclusive object within the Fischer implementation methodology.  A resource can be an account, a database role, membership in a native application group or just an attribute.  The important concept to grasp is that a resource is something required to build out a solution within Fischer.

Policies

As you become familiar with Fischer's product and feature set, you will find that the term "Policy" is used in multiple features.  The context is similar to the general definition of a policy.  A policy is the over-arching governance mechanism to enforce configurations within Fischer.  The term is used in the following contexts:

Object Category

Objects persist across the entire Fischer IGA Suite.  Every feature is encapsulated into an object.  Fischer does this so that objects themselves can be categorized into distinct authorization policies which will explicitly govern what actions are able to be taken and by who.  Categorizing objects provides IGA Administrators with an approach to distinctly govern specific features of the product.  The tricky part to understand is that you cannot create a new feature type, Fischer has (by default) organized all product objects into feature types already, and you cannot change this.  However, Fischer provides the ability to abstract a customized category into a specific feature.  This empowers administrators to add custom categories, which is the actual layer where access governance is enforced.  Once objects are categorized, administrators are then able to apply authorization policies at the category level and all associated objects will be governed by the defined authorization policies.  So, when building custom categories, conceptually IGA Administrators should be thinking about categorization in the context of their Identity ecosystem. An object category is a concept within Fischer that allows for categorizing features into specific, governance buckets.  Note that IGA Administrators are not able to change which product feature is assigned a listed Feature Type, however administrators can group features together into specific categories.  Out of the box, Fischer provides a list of global categories that enable the product to function with an operational authorization model in place.  The concept to understand at this point is that Object Categories provide for the ability to group features together.  An example of a customer Object Category would be "Active Directory".  If an IGA Administrator defined an Object Category called Active Directory, with the intent of placing all product features that involve the Active Directory, this would be a good name to choose to define the category.

Real World Example:

If IGA Administrators wanted to explicitly define custom authorization policies to separate individual connected systems into distinct authorization policies, therefore governing which Identities are authorized to administrate each connector type, they would need to define custom authorization categories per connected system (e.g. "Active Directory Category", "SAP Category", etc) and enable "Systems" only which would allow for the management of the endpoint integration. So, if a system owner accesses the administration user interface and only qualifies for the custom Active Directory Connector Management group, the only action he or she would be able to take would be within the Systems Tab (i.e. the Systems Feature Type seen below), and the only connected systems that would be visible would be those that are associated with the custom Active Directory authorization category, and you would associate the connected system to the custom Active Directory category when creating the connected system. 

An object category is a concept within Fischer's IGA Suite that provides IGA Administrators with the ability to categorize all "Feature Types" within the product.  A feature type is the method by which Fischer organizes all features across the Fischer IGA Suite.  Below is the list of fixed Feature Types IGA Administrators can work with.

User Groups

User Groups is the basic concept that is widely used within the industry.  It is simply the concept of grouping like users together with the intent to enforce or perform like actions that will affect all members of the group.  User Groups are used throughout the product and is a best practice approach for defining your native Fischer security and authorization model.  Fischer's grouping concept is applicable across multiple product features.  Building user groups provides IGA Administrators with the ability to determine how to govern access and functionality of the Fischer product and the corresponding features within it.  The user groups feature is applicable to multiple areas of the product.  For the purposes of this global explanation, defining User Groups helps IGA Administrators to efficiently and effectively define the global governance model within Fischer.  An example of a user group could be all users within a given department (Job-Department = X), or a more granular user group could be defined such as (Job-Title equals Help Desk Technician).  As you can see, user groups offers the ability and scalability to group like users together in multiple ways. 

Policy Indexes

A policy index is a way to group authorization policies together for evaluation.  It is a mechanism to help control how many policies are evaluated at run time.  When defining a policy index, an IGA Administrator would need to consider the evaluation scope and ensure that there is a corresponding attribute/value pair within each Identity Profile that resolves to a defined policy index.  When this happens, and Fischer's authorization engine detects a defined policy index in the Identity Profile, it will only evaluate the authorization policies that are relevant for the authenticating Identity type.  The biggest benefit of defining a policy indexing model is to help to control resource consumption at run time.  Specifically RAM, CPU, etc. that would be dedicated to the evaluation process at run time.

Conditions

Conditions is a concept that simply provides IGA Administrators to define the criteria that will result in resolution to actual Identities within the product.  It's important to note that Fischer builds conditions utilizing the Provisioning Hub Schema.  An example of a defined condition would be Job-Department equals Information Security.  At evaluation time, Fischer will retrieve all Identities that meet this particular attribute condition.

Rules

Rules are simply a combination of conditions.  Building a rule set provides IGA Administrators with the ability to combine defined conditions into a rule set.  At evaluation time, Fischer will evaluate each condition defined within a rule to determine if the authenticating Identity meets all conditions associated within the defined rule set.  Separating rules and conditions empowers administrators to re-use defined conditions in different context (i.e. rules).  This helps to limit duplication of effort and enables rules to be constructed (in some scenarios) with conditions that may also be leveraged for separate rules.  Rules are the foundation of ultimately qualifying Identities for authorization policies.  

System Owner

Fischer offers the "System Owner" context.  This concept provides organizations with the ability to define distinct system owners for each connected system.  System owners are often separated within Fischer's authorization security structure and are provided the "Connected System Administration" authorization policy.  System owners are also used when Administrative Provisioning is configured for a connected system and are the recipients of Administrative Provisioning requests.  Furthermore, Fischer extends the system owner feature to be available within the context of approval workflows where organizations can define a system owner approver list which will dynamically resolve to the users listed within the connected system as "System Owners".  This can be used to help govern access to connected systems as well as ensure that an organization can leverage Administrative Provisioning and ensure a complete audit trail by forcing system owners to report back to Fischer once an Administrative provisioning event has been completed.  Administrative Provisioning is defined in the Glossary of Terms.  Refer back to that if you need a refresher on Administrative Provisioning.

Sponsorship

Fischer offers a resource sponsorship feature.  The sponsor concept is applicable in a few areas of the product.  First, organizations are able to define a set of users that are considered sponsors.  A sponsor is an individual who is responsible for access to a particular resource.  IGA Administrators are able to build out resources to require sponsorship which will affect the end user's access request workflow.  This equates to an oversight mechanism from a governance point of view where sponsors can control access to their assigned set of resources.  This also creates a scalable administration model across all access able to be given out to identities.  This is different from an approver, however sponsors can also be approvers if an organization wants to do that.  This concept is a good one for larger organizations with a significant entitlement footprint and struggle with controlling who is accessing what, and more importantly ensuring that appropriate SMEs are given the necessary transparency within the IGA ecosystem to be involved in which identities end up with access to a set of entitlements.  

Identity Providers vs. Service Providers

The concept of Identity Providers (IdP) and Services Providers (SP) is one that creates a trust relationship for authentication and access control.  An IdP is by its own name an entity where identities and their associated attribute/value pairs are stored.  The information stored within the IdPs is what SPs use to abstract native authentication as well as rely on an external entity to provide the necessary identity information (i.e. attributes) that can identify an end user that is attempting to access it.  In short, service providers can be configured to trust one or many identity providers to handle authentication as well as packaging the necessary attributes an individual application (SP) will need to allow access.  This approach is discussed in detail in the Single-Sign-On Guide.

SAML

SAML (Security Assertion Markup Language) addresses the multi-domain single-sign-on use case by providing a standard protocol creating a trust relationship between multiple authentication stores in concert with multiple distinct and completely separate domains (i.e. separate entities) as well as offering a secured transport mechanism to transfer identity information which in turn authenticates users to applications.  SAML is an OASIS standard and is defined in an XML-based framework for exchanging security information between organizations.  The OASIS standard defines precise syntax and rules for requesting, creating and communications between applications and identity providers.

Federation

A Federation is a combination of service providers that want to build an aggregated trust model for accessing their applications. Federation is not a technical term in a sense that it provides any type of feature. Rather it is a method, leveraging technology (specifically SAML) to allow SPs to build a trust relationship with one or many IdPs where authentication is sourced. Often times organizations consider Federation as an actual technology. This is not true. It is the entity under which features such as single sign on are made possible in a way that is agreeable and predictable to all members of a Federation. It is important to distinguish this concept and to speak properly about it with customers. Fischer helps organizations configure their IdP-SP integrations, and those SPs may be in a Federation. If Fischer is working with a stand-alone customer, that decides to deploy SAML technology for authentication across all its applications, this is not Federation. This is SSO leveraging a single protocol as the engine to authenticate and create the necessary trust relationships to enable single sign on functionality for their end users. The term Federation is better used to describe the actual entities that are joined together, and should not be used when discussing any technical aspects of deploying the necessary and relevant components required to enable SSO.

Automated Provisioning

Automated Provisioning is often called by multiple names.  Fulfillment is a term that industry analysts uses to describe the use case of creating accounts in target systems with an effect of providing access to end users.  Access can come in the form of an account within an application, for example:Fischer Identity is rooted in governing identities.  On a broader scale, Fischer's functionality can extend beyond your standard IGA functionality in a way that competitors in the space.  While all core components of a full suite IGA product are available within Fischer, the way the software stack was built extends the consumer's capabilities well beyond just managing people and their access.  Typical use cases for automation within the context of IGA, which will be discussed at length, our features and functionality extend to automation in general.  Specifically business process automation, big data use cases, as well as features such as continuous monitoring and other abstract, ETL-driven automated tools required to provide our customers with a broader tool set at their disposal than most in the IGA marketplace.  Below is a table of the different features and the associated functionality that Fisher can provide our customers in the context of automation alone.  Many more features will be discussed, this table simply describes our automation capabilities.

 If you have a Gmail email account, Fischer can automatically create the account for an end user whose organization leverages Google for their corporate email provider. 

This is just one example of an account, but basically it equates to the created username/password combination that a user would use to access an application.  The automated provisioning feature connects to the target application and automatically creates the account as well as the password in some cases.

Automated provisioning can be broken further down into multiple, smaller sub-features as well. 

For example, in larger organizations where there is a human resources department, new hires are typically entered into the HR application first, this system is often referred to as the source of authority or “SoA”.  In IAM, this term is used on a regular basis and is considered the ultimate source of truth pertaining to any user that enters the organization’s network.  This helps the organization properly identify the employee within the organization by defining the employee’s job title, their job location, their distinct employee ID, as well as other information unique to the individual or the organization.

 In the IAM world, the creation of the user inside the SoA is considered an “event”. 

Automated provisioning has the capability to detect the action adding a new user to the SoA.  IAM integration with the SoA is also capable of detecting any modification events to the user as well.  Typical events are modifications to the user attributes (first name, last name, job title, action codes for job transfers, and so on).

Real-Time Event Detection (Triggers)

Events can be detected in real time, or immediately upon HR modifying the employee record.  The technology leveraged to detect events in real time is known as a trigger.  The industry nomenclature for this action is referred to as “real-time event detection”.  A trigger is a technical integration component that is constantly listening for changes within the SoA and the moment a change is made, the trigger will capture the change and communicate the change to the IAM solution for evaluation and processing.

Near-Real Time Event Detection (Delta Export)

While real-time event detection can provide organizations with a faster time to access for end users, if for some reason the integration breaks during the point in time when the trigger detects an action there is a very high potential that the action taken in the SoA can be lost and never communicated to the IAM solution.  As with any infrastructure, there are points of failure, and the network layer is often one that causes loss of communication with the network, in turn when the trigger detects an event and attempts to send the action to the IAM solution and if the connection between the SoA and the IAM solution is not available, the event can be lost.  It is important to note that the TCP/IP layer is outside of the control of the IAM solution and network deficiencies can lead to missed actions in the SoA which has the potential of leaving an identity within the IAM solution unchanged which can have security consequences.While real-time event detection is often a desired state for most organizations.  Deficiencies in technology, often lead IAM solutions to deploy “near-real-time” event detection (“NRT”).  NRT is a method used that provides the IAM solution to export user records from the SoA on a scheduled basis.  This approach may pick up N number of changes that occur from the last invocation of the SoA export as opposed to a real-time approach, with triggers that will only export the record of the user as soon as it changes.

NRT event detection is a preferred method of processing data from the SoA as it provides for the greatest level of transactional integrity and the level of predictability that organizations need to ensure SoA actions against user records are detected and communicated to the IAM solution for evaluation and processing.

Downstream Provisioning (Connected Systems)

Downstream provisioning is the actual process of provisioning an end user into an application, in turn creating a username and password for that user so they are able to access to the application.  IAM solutions integrate with many different system types.  A list of popular systems include relational databases, Active Directory, LDAP, Office 365, Google Apps, as well as many more.  Downstream provisioning requires an integration to the target system and the syntax of the integration will vary depending on the system itself.  The purpose of this document is not to get into the technicalities of the defining the actual syntax required for the IAM solution to integrate with a given system, rather the purpose is to provide you with an understanding that each target system is different and the provisioning requirements are different as well.

It is extremely important that readers of this document, as well as IGA Administrators understand that all features discussed below require zero knowledge of a specific programming language. Fischer has abstracted all the associated custom programming (via java, perl, PowerShell, etc.) where it makes sense so that subject matter experts familiar with their particular responsibility within a complete IGA Program are met with interfaces that make sense and are context aware. There is no compiling code, there are no include files to worry about, there are no function or method definitions including remembering parameter order or the functional syntax of how to call a method so the variables are passed in the proper order, and so on. Fischer has truly abstracted all of the heavy lifting into a powerful, extensible, scalable and best-of-breed IGA product suite.

Authorization Filters

On Behalf of Authorization Filters are a powerful way for organizations to govern which delegated administrators, managers, or other authoritative Identity types are allowed to take actions against.  This helps to build out a governance model necessary to ensure that Identities are managed by the proper personnel within the context they are to be managed.  So what does that mean?  It is important within IGA solution to govern who is able to take actions that can ultimately affect access within an organization.  Fischer's entity-based filtering allows for dynamic configurations to be defined and the product can be instructed at run time to resolve which users need to be managed or administrated by only authorized personnel.  A good example would be depending on an individual Identity's authority, an organization may not want that individual to be able to create new Identities directly  from Fischer, while other individuals with a higher security clearance would be able to create new Identities directly within Fischer.  Another example is related to the help desk / service desk.  Organizations want to be aware of who may be calling the help desk and which Identity is the beneficiary.  Fischer's authorization filters are there to govern that a person at a lower level in the hierarchy is not allowed to take any actions (reset passwords, lock, unlock accounts, view profile data, etc) for Identities that have a higher profile or higher security clearance.  In short, this filter can help you govern a scenario where you can block a standard help desk user from seeing an executives account or taking any action on it.  Within higher education a good example is you would leverage Fischer's authorization filters to make sure that a student worker, working for the help desk, would not be authorized to see any faculty identities.  This allows organizations to ensure that a student cannot reset the password for one of their faculty members.  There are many more examples where the authorization filter comes into play.  The goal here is to ensure that IGA Administrators understand the level of control and governance this feature can provide, and more importantly when IGA Administrators see this feature throughout the product they understand the context of what they are defining and how it will effect the security model of the organization.

Throughout the product, you will see the following feature:

This feature allows organizations to define a delegated administration hierarchy to govern which authoritative Identities are able to administrate and/or manage the profiles and access of other Identities.   The table below will explain how to use this feature.