Representational State Transfer (REST) is an architectural style that is based on Web-standards and the HTTP protocol. In REST based architecture, everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods. In REST architecture there is typically a REST server, which provides access to the resources, and a REST client, which accesses and modifies the REST resources. Resources are identified by global IDs (typically URIs), and can be accessed via the common HTTP operations (GET/PUT/POST).
The IdM Suite leverages the above technologies and specifications to expose RESTful Web Services for Password Management. The goal is to enable you to build your own portal or other Web applications and provide Identity Password Management functionality within that portal/application. This will enable users to reset their account passwords on various systems that Identity supports, all from within the convenience of their portal or in house application environment.
The Simple Cloud Identity Management (SCIM) specification is designed to make managing users’ identities in cloud based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model, as well as binding documents to provide patterns for exchanging this schema using standard protocols. SCIM provides a specification for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud Service Providers. Please refer to Updating SCIM Mapping guide to know how to change the SCIM mapping.
SCIM provides a specification to use for representing users and groups in JSON and XML formats. SCIM provides three different representations for a user:
- Minimal Representation
- Full Representation
- Enterprise Extension Representation
The IdM Suite supports the Full Representation and Minimal Representation.
It is important to understand that SCIM sits "on top of" REST. The SCIM layer is where you will define the attribute schema that will be retrieved via a REST API call. This is an important distinction to understand. SCIM is simply defining the attributes that the developer wants to return. For this reason, the SCIMUserProdAttributeMap.xml file will require manual configuration to properly represent Fischer's Provisioning Hub Schema in the context of the SCIM schema.
The table represents the list of supported actions when leveraging Fischer's API. The Use Case column is subject to preference but is intended to provide a bit of context around how you may want to leverage Fischer's REST Service within your application:
| Retrieval of Identity Data | |
|
An entity is able to retrieve identity data from Fischer's Identity Registry to be consumed by another application for various purposes. This can include reporting, display within the context of a native application or portal as well as many other scenarios. Note that the entire FISC_USER_PROFILE schema is available for retrieval via SCIM, however in a multi-tenant model manual mapping of custom attributes is required in order to retrieve the entire data set. Refer to the Implementing REST guide for more details on how to do this. |
|
| Governed Retrieval of Identity Data | |
| Fischer can enforce it's native authorization model even via API call to retrieve Identity data. If a user is authenticated to an external application with capabilities to retrieve information from Fischer's Identity Registry and that user is only authorized to view a subset of an organizations global Identity (user) population, Fischer will only return the list of identities they are authorized to view. | |
| Retrieval of a single Identity Profile | |
|
Third party applications integrated with Fischer via SCIM are able to retrieve attributes for a distinct Identity. In this scenario, if a user authenticates to a third party application, the application can leverage Fischer Identity Attributes to be returned and displayed in the external application. In this scenario, authorization is also enforced. |
|
| Abstracted Password Management | |
| For organizations that want to build their own help desk interface. With the ability to retrieve Identity data, including associated accounts, help desk technicians can leverage an external interface to reset passwords for end users. | |
| Account Info Retrieval | |
|
Developers have the ability to retrieve the username, the account_id, the current status of the account in two forms. (1) Whether or not the account is enabled (2) Whether or not the account is locked. |
|
| Account Validation | |
| Developers can offer the option within their external application to "Validate" accounts associated with an Identity. Validation is the process by which Fischer will initiate a connection to the Connected System associated with the Identity to check the validity of the account. Since Fischer stores the unique account_id in the Identity Registry, the product is able to connected and validate whether or not the account_id stored in Fischer is actually on the target system. An example of this would be if a developer wanted to validate the existence of an Active Directory account that is associated (within Fischer) to an Identity. If the DN is the account_id, Fischer's validation feature will perform a search against the Active Directory system and if the DN associated with the Identity exists, Fischer will return a message to the screen that the account is valid. | |
| Account Retrieval | |
| Developers can offer the option within their external application to display all accounts associated with a given Identity. In this context an account is the actual username and/or account_id value. This is useful information for externalizing audit, as well as organizations that already have third party tools in use for visualizing an Identity's footprint within the organization. | |
| Connected System Association Retrieval | |
|
Developers can retrieve the current Connected Systems associated with an Identity. By combining the retrieval of identity (attribute) data as well as retrieving the Connected System accounts (usernames or account_ids) and the Connected System associated developers are able to completely abstract the fundamental Identity data into their applications. Identity → Connected System(s) → Accounts. The combination of this information provides developers with 360 degrees of transparency with respect to an organization's Identity. |
|
| Password Reset Governance | |
|
Developers can retrieve the defined Password Enforcement Configuration ("PEC") associated with an Identity. This is important if an organization desires to abstract the password management interface from Fischer into their application. Refer to the Password Enforcement Guide for details about this feature. It is important to understand that Fischer only supports the abstraction of password reset enforcement for a single PEC. This feature may be not useful for organizations that have multiple PEC's defined. Fischer is working to expand support to include all potentially defined PECs. The use of this feature is mostly relevant in the scenario where an organization is offering single sign on and requires that all accounts for the user have the same password. |
|
| Password Policy Retrieval | |
| Developers can retrieve the password policy associated with Connected Systems. The context of representation is within the Password Enforcement Configuration retrieval. Since there can be multiple password policies (Fischer provides the ability to define a distinct password policy per Connected System) this object is represented as an array of password policies. Refer to the Implementing REST guide for more information. | |
| Reset Passwords | |
| Developers can build the password reset functionality into their application. This allows for password resets to be requested externally from Fischer's native interfaces. Refer to Implementing REST guide. | |
| Authorization & Governance | |
| Developers can retrieve a set of features a given Identity are allowed to use. An example would be "managerOtherProfiles", "resetPasswords", "validateAccounts",etc. The use of this feature will help developers to properly enforce the authorization configurations stored within Fischer to ensure that users within the third party application are only allowed to perform actions that are authorized by Fischer. | |
| Session Management | |
| Developers can perform session cleanup to remove the Self-Service session for the user that would normally persist in an SSO/Federated environment. When executed with a valid token, the user will be logged out of all open sessions in Self-Service. | |
| Application Access | |
| Fischer provides the ability to govern which applications end users are able to access within the context of SSO. For organizations that have their own end user landing page, but have chosen Fischer for Identity Provider services, developers can retrieve the list of applications an authenticated user is able to access. This will result in the end user only seeing the applications within their landing page they are allowed to access. |
Comments
0 comments
Please sign in to leave a comment.