Single sign-on (SSO)
Here we describe how to set-up single sign-on with LeanIX
Request an SSO setup
Follow this link to directly request an SSO setup for your workspace(s): https://leanix.zendesk.com/hc/en-us/requests/new?ticket_form_id=5897099761948
Overview
LeanIX implements single sign-on (SSO) using the SAML protocol. LeanIX can be configured to work with two kinds of Identity Providers (IDPs).
- internal IDP: the one you see when log in to eu.leanix.net
- external IDP: Companies provide their own IDP
Transient users with SSO
A great benefit of SSO integration with your (external) Identity Provider is the ability to enable Transient user roles. This allows users within your organisation to access a lightweight version of LeanIX via our Self-service Portals or Catalogs.
You can then embed these portals in your existing intranet, wiki or any other system sitting behind your SSO. You now have a great way to showcase data from within LeanIX directly, all without having to invite or create specific user accounts in LeanIX.
Basic Authentication Flow
When the user tries to access the LeanIX application in the browser, the Service Provider (SP) checks if the user if already authenticated. If not, then the user is redirected to the Identify Provider, which initiates the authentication (e.g. via username and password). After successful authentication, the user is redirected back to the Service Provider which grants access to the LeanIX application. The IDP provides attributes, e.g. email address, to the Service Provider which are used to properly identify the user within LeanIX.

SSO Authentication Flow
Supported IDPs
LeanIX is tested and works with IDPs which support the SAML 2.0 protocol, e.g.
IDP Name | IDP Documentation |
---|---|
Shibboleth IDP | https://wiki.shibboleth.net/confluence/display/SHIB2/ |
Microsoft Active Directory Federation Services (AD FS) | https://msdn.microsoft.com/en-us/library/bb897402.aspx |
Microsoft Azure AD | https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-federation-saml-idp |
CA Single Sign On | http://www.ca.com/de/securecenter/ca-single-sign-on.aspx |
Google IDP | https://support.google.com/a/answer/6087519?hl=en |
Okta | https://www.okta.com/topic/saml/ |
LemonLDAP::NG | https://lemonldap-ng.org/documentation/latest/idpsaml.html |
Checklist external IDP
Prerequisites:
- IDP must support SAML 2.0
- client browser needs network access to IDP
Required decision:
Is the role of a user maintained in LeanIX or IDP? (most customers choose LeanIX here)
-
Managed by LeanIX: Roles can be set during invite of a new user and can later be changed in the user administration. A default role (e.g. VIEWER) can be configured to be assigned to new users automatically on first access of a workspace. This means users can be provided with the link to LeanIX and they will be able to successfully login and be assigned the default role, for example VIEWER. All of this without having to "Invite" them to the workspace. In addition, the default role may be left blank. This means that ALL users would need to be "Invited" to the workspace via User Administration. In short authentication is done by the IDP and LeanIX handles authorization.
-
Externally managed: The IDP determines the role of a user and transfers it to LeanIX during the login process. Most customers map the membership in a Active Directory Security Group to one of the LeanIX roles. In short authentication and authorization is managed by the IDP.
Setup steps
- Customer provides metadata-idp.xml (exported from their IDP)
Guideline
Please make sure to send either a link to the metadata, or the XML in a Zip (in order to avoid problems with spam filter.
Please make sure to send the entire metadata, not only the certificate.
- LeanIX sets up a domain and configures it to use the customer's IDP. Once setup, the metadata of LeanIX is available at https://.leanix.net/Shibboleth.sso/Metadata
- Customer imports the LeanIX metadata and configures SAML attributes that LeanIX SP requires (see below).
Guideline
Please ensure that the name of every SAML 2.0 attribute exactly matches the name LeanIX SP expects.
- Customer tests the access to https://.leanix.net/
Troubleshooting
Make sure to test access only via https://.leanix.net/, not e.g. via https://app.leanix.net/; or https://us.leanix.net/; . We support login via SSO and username / password in parallel for the implementation stage. This will be deactivated in step 5.
We provide you a link with information on the current SAML session here: https://.leanix.net/Shibboleth.sso/Session . Please send us the result of this page in case something does not work.
Access via Internet Explorer can have problems, if the customer's IDP and LeanIX are in different zones, i.e. the IDP is in the zone "Intranet" while LeanIX is in the zone "Internet". It is then required to put the URL to your LeanIX instance, e.g. https://app.leanix.net into the list of trusted addresses in your Internet Explorer. In enterprises this is often controlled centrally, so please approach the team who define and manage the client configurations.
- Once successful, the login via LeanIX will be disabled (default IDP). For example prior to setting up SSO, you might be logging into LeanIX via us-2.leanix.net. Once SSO is successfully configured, login via the default IDP will be disabled. At which point login will only be possible via https://.leanix.net/
Hint
The uid needs to be unique within the LeanIX user base. Typically, it is possible that the IDP sends a uid that contains a customer suffix, e.g. [email protected] If this is not possible, we can also set this to "Managed By LeanIX". In this case, uids like uid=123456 are ok as well. Please inform us during configuration.
For Microsoft ADFS we provide a sample custom rule mappings, see https://dev.leanix.net/docs/sso-with-adfs.
Attribute Mapping
Please ensure that the name of every SAML 2.0 attribute exactly matches the name LeanIX SP expects.
Name | Format | Example | Comment |
---|---|---|---|
firstname | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | Peter | |
lastname | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | Schmidt | |
uid | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | [email protected] | Unique ID of user, stays stable even if Name is changed. Must be in e-mail format |
urn:oasis:names:tc:SAML:2.0:attrname-format:uri | [email protected] | ||
role | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | MEMBER | One of ADMIN, MEMBER, VIEWER. In case multiple roles are submitted comma-separated, then the highest role is taken. This attribute can be omitted if the role of a user is managed by LeanIX. For the SMP make sure to check the SMP user role mapping. |
customerRoles | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | MANAGER | This attribute is only relevant for customers who have designed and implemented their own custom roles. Please omit, if custom roles are not being utilized. For the SMP make sure to check the SMP user role mapping. As Admin, you can view and interact with workspaces under assumed user roles with Switch user roles feature. |
entryACI | urn:oasis:names:tc:SAML:2.0:attrname-format:uri | member-orgunit1 | The passed value must match the configured ACE in the workspace. This attribute is only relevant for Virtual Workspace and can be omitted otherwise. |
Example SAML Message
<saml2:AttributeStatement>
<saml2:Attribute FriendlyName="firstname" Name="firstname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
Peter
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="lastname" Name="lastname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
Schmidt
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="uid" Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
[email protected]
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="mail" Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
[email protected]
</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="role" Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
MEMBER
</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
SMP user role mapping
Note that ADMIN, MEMBER, and VIEWER roles will be mapped to different roles in the SMP.
In the SMP, the roles will be interpreted as the following mapping table shows:
Role in EAM/VSM | Role in SMP |
---|---|
ADMIN | admin |
MEMBER | user |
VIEWER | user |
ANY CUSTOM ROLE | user |
This applies for both cases when user roles are managed by LeanIX or when user roles are externally managed.
Information
SMP currently doesnβt support customer roles with external role management.
The βcustomerRolesβ attribute will be ignored.
Updated 2 months ago