Skip to main content

SAML Federation

In this example, we will set up Nevis to act as an IdP, than an SP using minimal settings and relying significantly on default values. It is good to understand what default behaviour is, but of course pretty much everything is configurable within the Identity Suite.

Additionally we will take the more standard approach to configuration order, where we will add the key patterns that you need, and than rely upon the nevisAdmin 4 interface to guide you in creating the additional supporting patterns as needed.

The following diagram helps with visualizing the setup, as working with key and trust stores can get confusing:

Set up Nevis as an IdP​

  1. Add a new "SAML IDP" pattern, and set it up the following way:
    1. In "Basic Settings", add your virtual host.
    2. Select your "Authentication Realm" pattern. In our example, a "Password Realm".
    3. For "Service Provider", create a pattern for a specific provider. When acting as an IdP, some of the settings are applied globally within the “SAML IDP” pattern whilst others are specific to each SP you wish to integrate with. Select “Add pattern", the UI will automatically select a “SAML SP Connector”. Rename it so the name reflects the target app/SP you are integrating with.
    4. For “SAML Signer” add a "nevisKeybox Store" pattern, or the "PEM Trust Store / PEM Key Store provider" patterns.
    5. From the “Advanced Settings” tab, change the "Authentication Type" from “default (sp-initiated)” to “both” if you want to test both IdP-initiated and SP-initiated flows, otherwise leave it on default.
    6. Save changes.
  2. Access the newly created key store pattern and rename it. In general you are free to name patterns as you wish. However, currently some parts of Nevis require that key stores must end with the word “Signer”, otherwise not all trust stores will be able to link to them.
    1. For “Owner(s)” select the “nevisAuth Instance” you created in Exercise C.
    2. Click the “Save changes” button.
  3. Access the newly created “SAML SP Connector” pattern from step 4, and change the name of this new pattern to “SAML SP Connector”.
    1. Within the “Basic Settings” tab, for “SP URL - Assertion Consumer Service(s)” specify a URL consisting of your own base URL followed by “/SAML2/ACS/”. (This will be the actual path used by the SP function when we create it in a later exercise.)
    2. For “SP Signer Trust Store”, select the dropdown and “Add pattern” and choose the “Automatic Trust Store” pattern.
    3. Save changes.
  4. Access the newly created “Automatic Trust Store” pattern from step 3.2., and change the name of this new pattern to “SAML IdP Trust Store”.
    1. Once we actually create the SAML SP config in the next lab, we can complete the configuration of this pattern by specifying the keys to trust. But for now, simply save changes.
Naming conventions

It is good practice to organise configurations, especially as more and more patterns are added. So we will tag each of the 4 new patterns with the label “SAML Identity Provider”.

For each of the 4 patterns created above, click the 3 dots next to the pattern name and create/select a label called “SAML Identity Provider”.

From the pattern list panel confirm that the “Group by: Label” icon visible. If not, the alternative “Group by: Ungrouped list” icon will be displayed. If necessary, select the dropdown and choose “Group by: Label”.

  1. Deploy your project to the “NEVIS” inventory as “Primary”.

Set up Nevis as an SP​

info

In the real world, Nevis will be acting as either the IdP or the SP, not both. But, in this exercise we will set Nevis up as both, so we can showcase all available functionalities.

  1. Add a new "SAML SP Realm" pattern, and set it up the following way:
    1. In "Basic Settings", for “SAML IDP Connector(s)”, select “Add pattern”. It will automatically create a “SAML IDP Connector” pattern.
    2. For “SAML Signer”, select “Add pattern”. Choose the “Automatic Key Store” pattern i.e. this is a new signing key store - do NOT use the existing keystore we created for signing as an IdP.
    3. For “Application Access Tokens”, select the “Nevis SecToken” pattern you created in the "Adding Local Authentication" section.
    4. Within the “nevisAuth Connection” tab, for “nevisAuth” select the “nevisAuth Instance” pattern you created in the "Adding Local Authentication" section.
    5. Within the “GUI Rendering” tab, for “Login Renderer” select the “nevisLogrend Instance” pattern you created in the "Adding Local Authentication" section.
    6. Save changes.
  2. Select the newly-created “SAML IDP Connector” pattern from step 1.1.
    1. On the “Signature Validation” tab, for “IDP Signer Trust Store”, select “Add pattern”. Choose the “Automatic Trust Store” pattern i.e. this is a new trust store - do NOT use the existing trust store we created for signing as an IdP.
    2. Save changes.
  3. Select the newly-created “Automatic Key Store” pattern from step 1.2. Name it “SAML SP Signer”.
    1. For “Owner(s)”, select the “nevisAuth Instance” pattern you created in the "Adding Local Authentication" section.
    2. Save changes.
  4. Select the newly-created “Automatic Trust Store” pattern from step 2.1. Name it “SAML SP Trust Store”.
    1. As we need this trust store to trust the IdP signing certificate within the same Nevis deployment, we can directly point to the “SAML IdP Signer” key store that we created in the previous lab. Make that assignment for the “Trusted Key Store” parameter.
    2. Save changes.
info

In this exercise we will also be testing the SP-Init flow which will involve our SP signing the request. For this message to be validated by the IdP, it is necessary for the IdP to have its own trust store that contains details of the SP signing certificate. If you recall in "Set up Nevis as an IdP" step 4.1, we hadn’t completed the configuration of that trust store (as it wasn’t needed for the IdP-init flow). In this next step, we will complete that config on the IdP-side.

  1. Select the “SAML IDP Trust Store” created in "Set up Nevis as an IdP" step 4.1.
    1. For “Trusted Key Store”, select the “SAML SP Signer” pattern you created in step 3.
    2. Save changes.
Naming conventions

It is good practice to organise configurations, especially as more and more patterns are added. So we will tag each of the 4 new patterns with the label “SAML Service Provider”.

For each of the 4 patterns created above, click the 3 dots next to the pattern name and create/select a label called “SAML Service Provider”.

At this point, the pieces are in place for your deployment to successfully issue and consume SAML assertions, BUT the target application we are using “Google Web App” is still configured to use local authentication via the “Authentication Realm” pattern setting. All we need to do is to reconfigure that web app so that it can use the new “SAML SP Realm”.

  1. Select the “Google Web App” pattern and within the “Basic Settings” tab, change the “Authentication Realm” setting to use the “SAML SP Realm” pattern.
Take care

If you simply click on the “Password Realm” pattern you will be taken to edit that pattern. Instead click the “x” on the right-hand side to remove the assignment. Then you can select the “SAML SP Realm” pattern.

  1. Save changes.
  2. Deploy your project to the “NEVIS” inventory as “Primary”.