Fischer also provides for the ability to configure authentication via IdP for a single sign on experience. Fischer provides an identity provider (IdP) and service provider services. By SP services, this means Fischer can itself be an SP for already deployed IdPs. This functionality is supported for authenticating to the Self-Service portal only. Refer to the Authentication Guide for a list of protocols Fischer supports.
Fischer's Identity Provider is based on the Shibboleth SSO Framework. Fischer provides a separate installation package for the IdP as it is an add-on service that organizations are able to utilize. Often times, organizations already have an incumbent SSO provider and Fischer's IdP is not needed, however there are many times when organization's want to consolidate their service offerings to a single vendor. Fischer's Identity Provider services support SAML 2.0 and CAS tickets. In some scenarios organizations are leveraging both CAS and Shibboleth to protect their applications. As of Shibboleth's version 3 IdP, both CAS and Shibboleth support is encapsulated into a single package and Fischer's IdP provides full support for both.
The concept of IdP is truly a mechanism of single sign on. The ultimate goal of offering SSO services is two fold.
(1) To provide a secure trust ecosystem through which applications can centralize their authentication.
(2) To offer end users with an elegant model where they only need to remember a single set of credentials.
Same Login Page
It's important to note that when Fischer's IdP is employed by a customer, regardless if the inbound authentication request is from a cassified or shibbolized service provider, the user will be shown the same login screen. The IdP has built in intelligence to determine if the inbound authentication request is from a CAS or SAML-based application.
Fischer's IdP supports both Windows and Unix/Linux Platforms
Virtual Identity Provider Support
If customers decide to leverage Fischer's Virtual (cloud-based) IdP they are essentially outsourcing their attribute store and Idp services including trust relationships with the customer's service providers (SPs). There are many details and configurations involved when building a Federation, and this guide will help you understand how Fischer's IdP and SP services function.
Proprietary Identity Provider Support
Fischer provides its own IdP solution which, when installed, enables SSO Administrators the ability to leverage Fischer's attribute repository as well as our granular authentication rules for primary and secondary (MFA) authentication. Fischer approach tightly couples the IdP to Fischer's Identity Registry providing a secure approach to deploying single sign on, as well as providing a secured mechanism to join Federations without the need to expose credential stores to the public internet, which in some cases Federations or certain service providers require.
While organizations can leverage a generic IdP that supports SAML or CAS to protect Fischer's self-service pages (as SPs) they will lose the ability and integration support Fischer's proprietary IdP offers.
The following is a glossary of terms that are extremely helpful to understand before you continue:
| IdP | |
| "IdP" stands for Identity Provider. This is a mechanism deployed by customers to enable single sign on. An IdP is simply a mechanism that abstracts authentication from applications and offers a method for users to enter a single set of credentials. The IdP possesses a trust relationship with the applications it is protecting therefore no direct authentication to applications is required by end users when Federation is deployed. The application is trusting the IdP to authenticate the proper user and relying on the IdP to send over the proper information (assertion) to inform the application which user is attempting to access it. Fischer currently leverages a form of the Shibboleth Identity Provider software to offer single sign on solutions and associated features. | |
| SP | |
| "SP" stands for Service Provider. A service provider is the application described in the above definition of "IdP". The SP is what end users need to access, and through various configurations (which will be outlined in the Federation guide) the SP entrusts the IdP to authenticate the end user as well as send the proper attributes required so the SP is able to identify the native user stored within its user repository and allow access. | |
| Authentication Flow | |
|
An authentication flow is a feature of Fischer's IdP. Fischer's proprietary IdP only supports a single authentication flow, which is the custom authentication flow that is used to leverage our dynamic authentication framework to allow for local authentication to occur inside an organization's firewall. This is primarily for our cloud customers that do not want to synchronize their active passwords to Fischer's cloud. Note that Fischer's IdP will always utilize the external authentication flow for GIG-based authentication. |
|
| EntityID | |
| This is a term used as the component that holds the unique identifier for the SP. While this value does not need to be an FQDN, the majority of the time it is. The EntityID is defined within the metadataproviders.xml file which is where each protected SP is listed for the IdP to reference. | |
| ImmuitableID | |
| Microsoft uses this as it's native distinguishing identifier for AD objects. This is an ADFS term. Organizations can define the immuitableID. When you install DirSycnh (Azure Synch) it is the default attribute defined. | |
| Relying Party | |
| The relying party refers to the relyingparty.xml configuration within the IdP itself. This file will also contain the EntityID as a reference to the metadataproviders.xml file and can provide further instructions regarding how the IdP should handle the authentication request. The relying party configuration can include additional instructions regarding encryption, consent, multi-factor, etc. | |
| Data Connector | |
|
The data connector is the defined endpoint within the attributeresolver.xml file where the IdP will connect to in order to retrieve the list of attributes from the server. Note that the IdP will return all attributes that are defined within the attributeresolver.xml file. There are other steps in the IdP process that will filter out the attributes that are required to build the assertion for the specific SP making the authentication request. |
|
| Attribute Resolver | |
| The attributeresolver.xml file is the location where attributes are defined within the context of single sign on. Different attributes may be needed for different SPs, so all attributes that are required for any SP assertion will need to be defined in the attributeresolver.xml file. This file will correlate the name of the attribute in the context of the IdP to the actual attribute it will resolve to in the data connector. | |
| Attribute Filter | |
| The attributefilter.xml file is the location where it is determined which attributes will be released from the global set of attributes returned during the attribute resolution process. | |
| NameID | |
|
The nameID is the unique value that is designated as the distinguishing identifier for the assertion. There must be at least one attribute defined as the nameID in order to move forward with building the assertion to be sent back to the SP. An example of nameID would be the loginID used within the SP to be able to distinguish one user of the application from the next. |
|
| Callback URL | |
| The callback URL is an important component of any authentication request. The callback URL is defined within the initial inbound request and is also stored in the SP metadata file. It is represented within an authentication request as the "AssertionConsumerServiceURL". Once the IdP has made it to the step where it is building the assertion to be sent back to the SP that requested authentication, the final check performed by the IdP is whether the callback URL sent inbound with the initial request is actually the same one that is stored in the SP metadata. This is a final security check in attempt to thwart any spoofing of authentication requests. If the callback URL is not present in the inbound request or if it does not match what is stored within the SP's metadata, the request will fail. | |
| Assertion | |
| An assertion is the process by which the IdP generates the necessary attributes to be sent to SPs so the SP knows which users is requesting access and more importantly what level of access the user will have. The SP controls the assertion requirements because each SP may utilize different Identity attributes to distinguish one user from the next. Therefore, building the assertion (which is the job of the IdP) must be done properly and within context of each individual SP. The SP contains a configuration which includes instructions to be sent to the IdP so the IdP knows which attributes the SP needs to identify the end user making the access request. The assertion process is contained within the IdP, but the definition of what to build and retrieve comes from the SP through a mechanism called metadata. | |
| Metadata | |
| Metadata is a configuration file provided by the SP. It contains various instructions and/or requirements for the IdP. Each SP that is integrated into a Federation must have a metadata file it can provide to the IdP. The metadata file is used to configure the IdP-SP relationship which includes the trust mechanism to use (i.e. the encryption signing to be installed within the IdP so the SP knows the inbound assertion is coming from a trusted source IdP) as well as the attributes the SP will accept (or requires to be passed) when it receives an assertion from the IdP. Note that not all metadata will contain certificates to be used for signing. In some cases, the SP will provide a mechanism to download the certificate or provide it to the IdP host. There are also scenarios where metadata can be an aggregate of multiple SPs in the case of entities such as InCommon where SPs can provide their metadata to a centralized broker which contains metadata for multiple SPs. | |
| CAS | |
| Central Authentication Service |
Comments
0 comments
Please sign in to leave a comment.