SAML2 Generic

Return to all applications.

• Log in as Tenant Administrator.
• Navigate to Applications | Gallery.
• Look for the application SAML2 Generic
• Click Configure.

General

In the General tab you can define the general information of the application.

• Enable the application.
• Provide a name that will be displayed on the end user portal.
• You can change the logo of the application.
• The Group set is used to group the applications on the end user portal.
• Set the application minimum Level Of Assurance.
• Use the option Display on Portal to allow this application to appear on the end user portal or not.

The Smart Links link is used to configure Smart Links for this application.

You can also access directly the Metadata file by clicking the Metadata File link. This file might help you to configure the application (or service) side of this trust relationship.

Parameters

The Parameters tab contains the list of settings required to configure the application.

• Issuer - Enter the identifier for CFS that has been defined in the application/relying party.
• Audience - Enter the SAML 2 parameter Audience. This value is a validity condition for an assertion as defined in the application/relying party. It declares that the assertion's semantics are only valid for the relying party named by the URI set in this parameter.
• Recipient - Enter the SAML 2 parameter Recipient. This is the URL on the application/relying party to redirect the user back to (with the token) after they are authenticated by CFS.
• Relay State - Enter the SAML 2 parameter Relay State. This is used to transfer a context between the relying party and CFS and is usually passed dynamically during the authentication process during RP-initiated SSO. This can be left blank.

• Signature Algorithm - Algorithm to use to sign the token.
• Digest Algorithm - Algorithm to use to generate the digest of the token.

Import Metadata

Starting in CFS Version 3.16.2, an application's metadata can be imported into CFS using the Import Metadata feature.

The data can be imported from either an XML file, or from a URL. The data will be parsed, and the appropriate parameters (i.e. issuer, auidence, recipient, relay state) will be filled in. The fields that were not found in the metadata will be removed, but the existing fields will still be modifiable.

The following images show an example Generic SAML 2 application that used the import metadata feature in which the relying party's metadata provided only issuer and ACS values.

Before the import, the parameters tab shows the following:

After the import, it shows:

Mappings

The Mappings tab contains the list of transformation required to generate the output token claims. Since this application supports it, you can send additional claims in your token. Click the "New Mapping" button to add a new mapping.

The Access Rules tab helps define the second layer of security (after LOA) to grant access to this application. By default, the access is limited to only the people in the Application Group which is a group created automatically by CFS when the application is created. To grant access to this application you have 3 possibilities:

• Allow All Users by checking this option, you will grant access to every user of your tenant (as long as the other security layers, LOA, COT... are accepted for the user).
• Use the Application Group to add users allowed to access this application. The users who are granted access to the application after an access request are automatically added to this group.
• Add Additional groups from the RadiantOne identity store.

![]media/saml2-generic-tab-access-rules.png)

Filters

The Filter tab is another security layer that allows to filter the access to the application by using the context of the user. This context is based on the attributes of the user retrieved from the RadiantOne identity store and the attributes generated by CFS like the Circle of Trust.

Certificate

The Certificate tab is used to define the certificate used by CFS to build the signature of the token it generates for the application. When configuring the application (or service), provide the public key of this certificate so the application can ensure that only CFS could have generated and signed the token. There are 3 options to provide this certificate to the application.

• Default Tenant Certificate - CFS generates a certificate for each tenant and stores it the RadiantOne identity store. This is the default certificate that is used for all applications.
• Upload a private key - You can upload your own certificate (private plus public key) and it will be used for this application only. This certificate is stored in the RadiantOne identity store, and can be used from any CFS machine.
• Upload a public key - You can upload your own certificate (public key only). This public key is stored in the RadiantOne identity store, but the private key must be installed in the Windows Vault and made available on each CFS machine that will sign the application tokens. This is the most secure way to sign a token because the private key never travels on your network between the RadiantOne identity store and the CFS machines.