Single Sign-On using SAML
This topic provides an introduction to how ASM Core can be configured for Single Sign-On (SSO) using Security Assertion Markup Language (SAML) and the technical requirements to use this functionality.
This topic provides an introduction to how ASM Core can be configured for Single Sign-On (SSO) using Security Assertion Markup Language (SAML) and the technical requirements to use this functionality.
Copyright 2023 Alemba, ASM EOS 10.4
This feature is only available on SQL systems.
ASM Core Analysts and Users will typically need access to a large number of internally and externally hosted (Cloud) applications each requiring usernames and passwords. Identity federation helps to solve this issue by providing a secure mechanism for sharing identities and therefore removing the need to maintain a separate user profile for ASM Core.
SAML is an identity federation standard language that enables SSO without the need to remember passwords and is a convenient way to access web applications due to enhanced security. It limits potential risks by eliminating the need for extra web application passwords by establishing a trust between the ASM app and the Organization's Federated Identity system(s).
The ASM User or Analyst makes a request to access the application by loading an appropriate ASM URL in a browser.
The ASM app will detect this request and generate a SAML request.
This is sent to the Identity Provider via the User/Analyst’s browser, with the SSO URL.
The Identity Provider, MS ADFS or other Partner, checks the request and then authenticates the User/Analyst.
The SAML Response is generated.
It is then passed back to the ASM URL via the User/Analyst’s Browser.
If you are using ADFS, the details that are sent are called ‘claim rules’ and are configured within ADFS when creating the relying party trust. See Importing Service Provider metadata into the Identity Provider for more details.
7. ASM verifies this response. it tries to fiend an existing user. The criteria it uses depend on whether SSO is enabled within the Service Provider. If disabled, the application will always attempt to match the ‘NameID’ (set within the ADFS claim rules) with the ‘LoginID’ of the user. If the SSO resource has been enabled, resource mappings can be configured to match alternative fields instead of the default ‘LoginID’.
See Importing Service Provider metadata into the Identity Provider for more details. It operates in the same way as normal integration; the first time a user is encountered the resource mapping matching tab is used and thereafter the external resource link is used.
8. If a user is found, they are logged in. If not, and there is an existing account in AD and the SSO resource has been selected within the service provider, a new user is created using the resource mapping.
If SSO is disabled, the login process will fail and no user account will be created.
Federated Identity is the means of linking a person’s electronic identity across multiple distinct identity management systems.
Single Sign-On is a property of access control of multiple related but independent software systems allowing a user to log in to ASM Core with a single ID and password.
SAML is an XML based open standard for exchanging authentication and authorization data between for instance, an application with a user’s own organizational log in credentials.
Service Provider (sP) in this case is the application for which Users are attempting to access and log in to i.e. the ASM app.
Identity Provider (IdP) is the source of the SAML service (e.g. ADFS, Shibboleth) which provides the Service Provider (ASM app) with the authorization for users to log on and use the application.
