SAML 2.0 – Support Portal

Let's start with a diagram that focuses on how Fischer offers IdP protection to (SAML 2.0) Service Providers. As stated, Fischer offers a proprietary IdP installation that will dynamically link the IdP to the Fischer product in order to take advantage of our governance and security features embedded into our product as well as our Dynamic Authentication capabilities (e.g. Fischer's Authentication Rules as depicted below). Below is a diagram that will provide you with an in depth look at exactly how Fischer's IdP functions and how it leverages the IGA ecosystem to offer a more secure single sign on solution when leveraging it, as opposed to a generic IdP.

There are two types of requests that can initiate an IdP session. (1) SP-Initiated, (2) IdP Initiated.

SP-Initiated Request

An sp-initiated request is one that is invoked by the end user attempting to access an application URL directly. Upon receiving the request, if the application is configured to re-route the authentication request to an IdP, it will contact the IdP and initiate the authentication request. Since the application (SP) is contacting the IdP and asking to handle the inbound request to access the application, and the application is configured to outsource the authentication layer to an IdP, this is called an SP-initiated request. The diagram depicts how an SP-initiated request will flow through Fischer's IdP.

Note exceptions table below for further clarity and nuances that may change the flow.

Can the IdP Honor the Request?
Can I process the requested authentication flow? This will fail only if the SP explicitly requests an authentication flow that is not enabled. This will immediately fail the request and throw an error to the end user's browser. If the initial SP request passes in "forcedAuth=(true)", the IdP would check the IdP.properties file to see what authentication flows are available to it, next it would check the general-auth.xml to see what the available flows support. If it supports forcedAuth, the login page would render if the authentication flow does not support Forced it would fail and throw an error to the browser. If the initial SP request passes in the passiveAuth=(true). Passive authentication is intended to not require credentialing, and Fischer does not support Passive Authentication. Is there metadata? If there is no metadata, an error will be thrown that there is no relying party for this service provider. Is there a defined relying party? If there is not a defined relying part and metadata is present it would advance using the default relying party. Is the request encrypted? And can I decrypt the request? If the authentication request is encrypted, the IdP needs to retrieve the CSA in the SP metadata, if the CSA is not present in the metadata the request cannot be decrypted and an error will thrown stating as such OR the certificate pairing may be stale. This is why we want to always use URL based metadata so if the signing pair changes we are only 24 hours behind (24 hours if the refresh period to put on the metadata)

Render IdP Login Screen
There are no exceptions to this. The login screen will always be within the authentication flow. ECP Exception! If ECP is required (primarily for Office 365 and mobile devices) users are not technically authenticating into the IdP, the authentication request is diverted to Apache. Apache will validate the user and pass that back to the IdP and utilize the remote user internal authentication flow and continue. For this to happen, Apache requires the ldap auth moduel installed to allow it to can initiate a custom auth file with the ldap connection information, it will do the ldap authentication to validate username and password directly. Keep in mind that the ECP protocol is evolving and ModernAuth is the fix for this specific issue and it is available as a configuration option within Office 365. If possible, we strongly recommend customers to leverage ModernAuth as it will allow the IdP process to function properly (i.e. render the correct login screen). If ECP is used, the user will receive an Apache-based login screen which is a grey box with a username and password input box which is not an elegant user experience.

Fischer Identity Registry
ECP Exception! In the ECP scenario, the IdP will NOT lookup to Fischer's Identity Registry. ECP will bypass the external authentication flow which in turn will bypass all auditing and trace of user authentication. We need to look into HTTPD access logs or the idp-audit.log to be able to see authentication requests.

Fischer Authentication Rules
ECP Exception! If ECP is required, Fischer Authentication Rules cannot be used. This means that MFA cannot be available for mobile phone login. If ModernAuth is a new version of Microsoft's SAML protocol for Office 365 and if this was enabled, the standard processing would occur. ModernAuth is turned on at the Office365 level. Mobile devices will always use ECP and we throw up a blank username and password screen. If ECP customers do not want their LDAP to be public then mobile-device authentication will no longer work.

Attribute Resolution
For the scenario where attribute resolution does not return attributes, this may inf act be a valid. Some service providers simply want to verify that there is a verified Identity that is stored within the realm (or Federation) to allow access to the application. Some applications do not care about who you are, just that you are coming from a trusted IdP.

Attribute Filtering
There are no exceptions to consider at this layer of the IdP process.

Assertion Construction
For encyprting, it will use the Idp CSA to encrypt the assertion, and the accompanying public key must reside in the SP metadata so the assertion can be encrypted.

IdP Initiated Request

IdP initiated requests will act a bit differently in terms of how the request is processed by the IdP. In this scenario, the end user will first access the IdP and authenticate, creating an "IdP Session". Once the IdP session is established, end users are most often directed to an application portal or a "landing page". This page will contain a list of accessible service providers. End users simply click on the link to the application, and the IdP will then initiate a request to the SP with all the required information to allow for the SP to properly handle the request. The technicalities of this process are largely the same as an SP initiated request, however the flow is a bit different. Please see the diagram below where the processing is a bit different when the IdP initiates the request.

Abstracted URL for Idp-initiated
It is important to understand that the IdP ALWAYS needs a URL to validate before it can do anything. If there is no URL provided, the IdP does not know what to do and it will fail immediately. In the case of IdP-initiated requested, an abstracted URL must be presented to the IdP. This can be an internal, customer URL that is used for the IdP to initiate the session. In this scenario, the actual target URLs (the real one from the service provider) the end user will access are abstracted for the sole purpose of initiating the IdP session. Idp vs. SP initiation is largely controlled by two primary items: (1) Does the service provider only support IdP-initiated requests? If this is the case, then a custom URL must be created and the target (callback URL) is embedded in the metadata to be retrieved at execution time (i.e the IdP is attempting to authenticate a user on behalf of the SP). OR (2) The customer has decided to provide end user with a landing page which presents all applications they are allowed to access. In this scenario, the landing page URL would be considered the initiation point of the IdP session. It may get confusing, however the primary point to understand is that while IdP initiated requests are supported, the IdP will always need an SP URL to be able to work. If there is a landing page, the URL leveraged to initiate the IdP session would in fact be a service provider URL. The SP would just be the landing page itself.

Accessing the IdP login screen
It's important to note that the actual URL of the IdP login screen is most likely directly accessible, however there must be an entity configured to send the user somewhere. Users cannot simply authenticate within their browser and then all of the sudden they have an active IdP session. The IdP needs to protect something (URL) and while it is possible to redirect you back to the same location you are at when you authenticated just without the login screen, you have to know that an authentication event did occur and the underlying entity that was authenticated is the URL that is protected behind the IdP login screen, which can be an abstracted URL or a separate application altogether, but the IdP does not care about the the user experience, just that it has all the necessary configurations in place (per the diagrams above) to work and do its job successfully.