Add a SAML 2 IDMS

Follow

Add a SAML 2 IDMS

SAML 2.0 provides authentication between a service provider and an identity provider. Kion is the service provider that will use your identity provider (Active Directory, Okta, OneLogin, PingFederate, Google, etc.) to authenticate the users into the application.

These instructions assume the Kion (service provider) URL is https://Kion.example.com and the identity provider URL is https://idp.domain.com. When you see these example URLs, replace them with the URLs specific to your environment.

Obtaining Information from your Identity Provider

Before creating a SAML IDMS in Kion, you must obtain the following information from your identity provider. This process varies from provider to provider. See your specific identity provider's help documentation for more information.

  • Identity Provider Metadata
  • Identity Provider Issue (Entity ID)

Adding a New SAML IDMS inKion

  1. In Kion, navigate to Users > Identity Management Systems
  2. Click Add New
  3. For the IDMS Type, select SAML 2.0.
  4. Enter a name to describe the IDMS. Users see this name when selecting the IDMS on the Kion login page.
  5. For the Identity Provider Issuer, enter the URL that will issue the SAML 2.0 security token (https://idp.domain.com). This is typically known as the Entity ID for the identity provider and it can be found in the metadata.
  6. For the Identity Provider Metadata, paste in the metadata from the identity provider. It should be in XML format.
  7. For the Service Provider Issuer, enter your Kion URL. Typically, this value is auto-filled and doesn't need to be changed (https://Kion.example.com/api/v1/saml/auth/1). This value is the Entity ID for Kion.
  8. The Service Provider ACS URL automatically populates the callback URL (https://Kion.example.com/api/v1/saml/callback). This is the callback/redirect URL the identity provider should use when sending the SAML assertions to Kion.
  9. (Optional) For the Audience URI, enter the Service Provider Issuer Entity ID (https://Kion.example.com/api).
  10. (Optional) For the Allowed Auth Context, enter an allowed value. For more information, see the Authentication Context documentation. An example of an allowed value is: urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken.
  11. (Optional) For the Auth Context for Privilege Elevation, enter an allowed value that will provide the user with the ability to access the cloud console. If this field is blank, console access will not be limited by auth context. For more information, see the Authentication Context documentation. An example of an allowed value is: urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI.
  12. (Optional) For the Name ID Format, enter a format to use for name IDs. For more information, see the Authentication Context documentation. An example of an allowed value is: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified.
  13. If requests are signed, enable Should Sign AuthN Requests.
  14. Enable Enable Single Logout to automatically invalidate and end the SAML session when a user logs out of Kion.
  15. Enable Enable Custom Login URL to direct users to log in using an external URL. Once enabled, add your custom URL in the Custom Login URL field.
  16. Select a Canonicalizer.

Assertion Mapping

  1. For the First Name, enter the field from the IDP that will be mapped to the user first name (first_name).
  2. For the Last Name, enter the field from the IDP that will be mapped to the user last name (last_name).
  3. For the Email, enter the field from the IDP that will be mapped to the user email (email).
  4. (Optional) For the Phone Number, enter the field from the IDP that will be mapped to the user phone number.
  5. For the Username field, enter the field from the IDP that will be mapped to the user username (username).

Validation and Access Rules

Create Validation Rules and Access Rules as necessary. These fields read the SAML assertions by name and then apply the regular expression to the value of the assertion. The regex simply returns either a true or false based on the expression.

Validation Rules. Use SAML assertions to control which users can log into Kion. If any of the expressions return false, the user cannot log into Kion.

Access Rules. Use SAML assertions to set the level of console access available to users. If no access rules are specified, then all users have Full Access. If any access rules are specified, then all users have No Access except those who are specifically granted access.

  • Full Access. Users may use cloud access roles to access the cloud consoles. This access only applies to cloud access roles, not other functions within Kion.
  • No Cloud Account Access. Users can log in and use the Kion application, but they cannot access any cloud accounts.

    This is useful if you allow users to log in with a SmartCard instead of a password. Typically, users with a SmartCard would be granted Full Access while users with just a password would be granted No Cloud Account Access.

  • No Access. Users are not allowed to log into Kion.

Service Provider Icon

You can upload a custom icon to show on the login screen next to this IDMS.

You can also select if you would like to hide this IDMS as an option on the login page.

Generating a New Application in the Identity Provider

This process varies from provider to provider. See your specific identity provider's help documentation for more information.

The information required from Kion will typically be the Service Provider Issuer and the Service Provider ACS URL found in the Add IDMS form.

User Group Associations

Automatically add users to user groups in Kion based on SAML assertions. This is useful for dynamically determining user permissions. For more information, see User Group Associations.