SSO Examples

1 - KeyCloak SAML Example

Configuring SAML SSO for Anchore with KeyCloak

The JBoss KeyCloak system is a widely used and open-source identity management system that supports integration with applications via SAML and OpenID Connect. It also can operate as an identity broker between other providers such as LDAP or other SAML providers and applications that support SAML or OpenID Connect.

The following is an example of how to configure a new client entry in KeyCloak and configure Anchore to use it to permit UI login by KeyCloak users that are granted access via KeyCloak configuration.

Configuring KeyCloak

Anchore supports multiple IDP configurations, each given a name. For this example we’ll choose the name “keycloak” for our configuration. This important as that name is used in several URL paths to ensure that the correct configuration is used for validating responses, so make sure you pick a name that is meaningful to your users (they will see it in the login screen) and also that is url friendly.

Some config choices and assumptions specifically for this example:

1. Let’s assume that you are running Anchore Enterprise locally. Anchore Enterprise UI is available at: https://localhost:3000. Replace with the appropriate url as needed.
2. We’re going to choose keycloak as the name of this saml/sso configuration within Anchore. This will identify the specific configuration and is used in urls.
3. Based on that, the Single-SignOn URL for this deployment will be: https://localhost:3000/service/sso/auth/keycloak
4. Our SP Entity ID will use the same url: http://localhost:3000/service/sso/auth/keycloak

Add a Client entry in KeyCloak

1. See SAML Clients in KeyCloak documentation

2. For this example, set the following values in “Add Client” screen (these are specific to the settings in this example described above):

   1. Client ID - http://localhost:3000/service/sso/auth/keycloak - This will be the SP Entity ID used in the Anchore configuration later
   2. Client Protocol: “saml”
   3. Client SAML Endpoint: “http://localhost:3000/service/sso/auth/keycloak”

3. In the next screen, Client Settings

   

   1. Name - “Anchore Enterprise”. This is only used to display a friendly name to Keycloak users in the KeyCloak UI. Can use any name you like.

   2. Enabled - Select on

   3. Include Authn Statement - Select on

   4. Sign Documents - Select on

   5. Client Sign Authn Requests - Select Off

   6. Sign Assertions - Select off

   7. Encrypt Assertions - Select off

   8. Client Signature Required - Select off

   9. Force Post Binding - Select off. Anchore requires the HTTP Redirect Binding to work, so this setting must be off to enable that.

   10. Force Name ID Format - Select on

   11. Name ID Format - Select username or email (transient uses a generated UUID per login and persistent use the Keycloak user’s UUID)

   12. Root URL - Leave empty

   13. Valid Redirect URIs - Add http://localhost:3000/service/sso/auth/keycloak

   14. Base URL - Leave empty

   15. Master SAML Processing URL - http://localhost:3000/service/sso/auth/keycloak

   16. Fine Grain SAML Endpoint Configuration

       1. Assertion Consumer Service Redirect Binding URL - http://localhost:3000/service/sso/auth/keycloak

   17. Save the configuration

   

4. Download the metadata xml to import into Anchore

   1. Select ‘Installation’ tab.
   2. Select Format
   • Keycloak <= 5.0.0
   1. Select Format Option - SAML Metadata IDPSSODescriptor
   • Keycloak 6.0.0+
   1. Select Format Option - Mod Auth Mellon files
   2. Unzip the downloaded .zip and locate idp-metadata.xml
   3. Download or copy the XML to save in the Anchore configuration

Configure Anchore Enterprise to use the KeyCloak

1. You’ll need the following information from keycloak in order to configure the SAML record within Anchore:

2. The name to use fo the configuration, in this example keycloak

3. Metadata XML downloaded or copied from the previous section

4. In the Anchore UI, create an SSO IDP Configuration:

5. Login as admin

6. Select “Configuration” Tab on the top

7. Select “SSO” on the left-side menu

8. Click “Let’s Add One” in the configuration listing

1. Enter the values:
   1. Name: “keycloak” - This is the name of the configuration and will be referenced in login and sso URLs, so we use the value chosen at the beginning of this example
   2. Enabled: True - This controls whether or not users will be able to login with this configuration. We’ll enable it for the example but can disable later if no longer needed.
   3. ACS HTTPS Port: -1 or 443 - This is the port to use for HTTPS to the ACS (Assertion Consumer Service, in this case the UI). It is only needed if you need to use a non-standard https port
   4. SP Entity ID: http://localhost:3000/service/sso/auth/keycloak (NOTE: this must match the Client ID you used for the Client in the KeyCloak setup
   5. ACS URL: http://localhost:3000/service/sso/auth/keycloak
   6. Default Account: keycloakusers for this example, but can be any account name (existing or not) that you’d like the users to be members of. See Mappings for more information on how this
   7. Default Role: read-write for this example so that the users have full access to the account to analyze images, setup policies, etc.
   8. IDP Metadata XML: Paste the downloaded or copied XML from KeyCloak in step 4.3 above
   9. Require Signed Assertions - Select off
   10. Require Signed Response - Select on
   11. Save the configuration

You should now see a ‘keycloak’ option in the login screen for the Anchore Enterprise UI. This will redirect users to login to the KeyCloak instance for their username/password and will create a new user in Anchore in the keycloakusers account with read-write role.

2 - Okta SAML Example

Configuring SAML SSO for Anchore with Okta

Some config choices and assumptions specifically for this example:

1. Anchore UI endpoint: http://localhost:3000. Replace with the appropriate url as needed.
2. IDP Config Name: okta. This will identify the specific configuration and is used in urls, and can be any url-safe string you’d like.
3. The Single Sign-on URL (also called the Assertion Consumer Service/ACS URL) for this deployment will be: http://localhost:3000/service/sso/auth/okta. This is constructed with the UI endpoint and path /service/sso/auth/{IDP Config Name}
4. Our SP Entity ID will use the same url: http://localhost:3000/service/sso/auth/okta. This could be different but for simplicity we use the same value.

Configure Okta: Add an Application

See Okta SAML config to see how to create a new application authorization server. The following steps are used during specific steps of that walk-thru

1. In step #6
   1. Single sign on URL, this is the URL Okta will direct users to. This must be a URL in the Anchore Enterprise UI based on the name you chose for the configuration. In our example: http://localhost:3000/service/sso/auth/okta
   2. Set the Use this for Recipient URL and Destination URL checkbox as well. a1. Set the Audience URI(SP Entity ID) to a URI that will identify the anchore installation. This can be the same as the single-sign-on URL for simplicity. We’ll need to enter this value later in the Anchore config as well.
   3. Leave Default RelayState empty
   4. Name ID format can be left “Unspecified” or set to an email or username format.
   5. Choose the application username that makes sense for your install. Anchore can support a regular username or email address for the usernames.
2. In step #7, these attribute statements are not required but can be set. This is, however, where you can set additional attributes that you want Anchore to use to initialize the user’s Anchore account or permission set. Later in the SAML Configuration you can specify attributes that Anchore will look for to extract the account name and roles for initializing a user that doesn’t yet exist in Anchore.
3. In step #9, be sure to copy the metadata URL link so you have that. Anchore will need that value.
   1. Right-click here and copy the link address: The URL should be something like: https://<youraccount>.okta.com/app/<appid>/sso/saml/metadata
4. Finish the setup and save the Application entry.
5. Important: To allow Okta users to login to Anchore you need to assign the Okta user to this new Application entry. See Assign and unassign apps to users for information on this process.

Configure Anchore Enterprise to use the Okta Identity Provider

You’ll need the following information from okta to enter in the Anchore UI:

• The name chosen for the configuration: okta in this case
• Metadata XML URL (from “configuring okta” step 3.1 above)
• The Single Sign-on/ACS URL described in Step 3

In the Anchore UI, create an SSO Idp Configuration:

1. Login as admin
2. Select “Configuration” Tab on the top
3. Select “SSO” on the left-side menu
4. Click “Let’s Add One” in the configuration listing

And…

1. Enter the values:

   • Name: okta - This is the name of the configuration and will be referenced in login and sso URLs, so we use the value chosen at the beginning of this example
   • Enabled: True - This controls whether or not users will be able to login with this configuration. We’ll enable it for the example but can disable later if no longer needed.
   • ACS HTTPS Port: -1 or 443 - This is the port to use for HTTPS to the ACS (Assertion Consumer Service, in this case the UI). It is only needed if you need to use a non-standard https port
   • ACS URL: http://localhost:3000/service/sso/auth/okta
   • Default Account - The account to add all okta users to when they login, for this example we use oktausers
   • Default Role - The role to grant okta users when they login in initially. For this example, we use read-write, the standard user type that has most abilities except user management.
   • IDP Metadata URL - The url from “Configure Okta” step 3.1
   • Require Signed Assertions - Select On
   • Require Signed Response - Select On

2. Save the configuration, configuration is complete when you see a login with ‘okta’ option on the login screen. Users can now log in to your Anchore deployment using this Okta endpoint.

See: Mapping Users and Roles in SSO for more information on using the account and role defaults, IDP attribute values and understanding how identities are mapped into Anchore’s RBAC system.