One Touch token
Performing this scenario will produce a SAML IDP validating an access token issued by One Touch using either Active Directory, LDAP or SQL database as the primary userstore. Be sure to have configured "Keystore" & "SAML meta upload" scenarios prior to executing this scenario.
To enable access from within the One Touch profile the server needs to "aware" of this configuration. This is done by configuring "One Touch actions".
Se how here
Not that this method of authentication does not have any means of user input, UI. Using One Touch tokens also implies for unsolicited SAML behavior.
This article will use LDAP as the primary user store.
Name & Description
Start by giving the scenario a friendly name and description. Then click Next.
User store selection
Select existing or create new primary user store.
User search settings
Enter a search filter. This will be used to locate the authenticating user. Configure the search base by browsing through clicking "Choose" or manually enter the search base root. None of the values may be blank.
Entity ID & POST SSO settings
Configure the entity id of this IDP. Note that this ID MUST be unique within the federation and installation of the PhenixID system.
Post SSO URL must be accessible for the clients targeted for this SAML federation. Pattern of the POST SSO URL must by in the format <http/https>://<host>/saml/authenticate/<unique_identifier>
The ending unique identifier is what is used by the system to route the request to the appropriate IDP.
Select one of the keystore uploaded earlier.
Enter the attribute used as the user identifier. This is the attribute the user will enter at login. This is also the value that will be marked as the nameid in the assertion token. Any additional attributes incorporated in the assertion (SAML Attribute statement) is entered in the "Additional attributes" section. Multiple attributes are separated by comma.
Select the default service provider used when performing unsolicited SAML. Solicited requests will be handled automatically, using the SP entity id from the SAML authentication request. The list of known SPs is provided through the sum of all metadata uploaded.
Note that only unsolicited requests is supported making a default SP mandatory in order for authentication to work.
Click create and after a couple of seconds the IDP is ready to handle incoming authentication requests.
Additional configuration or deletion is done by expanding the heading and clicking the desired name of what needs to be edited.
The guide will ensure that 2 modules are deployed: