UMANTIS CLOUD SSO CONFIGURATION GUIDE WITH MICROSOFT ACTIVE DIRECTORY FEDERATION SERVER THIS DOCUMENT DESCRIBES THE REQUIREMENTS TO SETUP A SINGLE SIGN ON (SSO) CONFIGURATION ON UMANTIS CLOUD BASED SOLUTIONS AGAINST A CUSTOMER S PRIVATE ACTIVE DIRECTORY FEDERATION SERVER (ADFS) Author: Mallku Caballero, Marc Elser Document Version: 1.08 Haufe-umantis AG Untertrasse 11 CH-9001 St. Gallen Tel. +41 71 224 01 01 Fax +41 71 224 01 02 umantis@haufe.com www.haufe.com/umantis
AUDIENCE This document is intended primarily for umantis Technical Consultants and customers IT departments. 2
PRE-REQUISITES The customer is responsible for installing Microsoft Active Directory Federation Server version 2.0 (with Update Rollup 3 or newer) on top of his existing Active Directory infrastructure. The details for this installation and general configuration are not covered in this document. An understanding of the SAML SSO protocol is useful but not absolutely required. Some basic elements are presented in this document but the reader is encouraged to seek relevant resources (e.g. http://saml.xml.org/saml-specifications) for a more complete description. 3
SAML PROTOCOL ELEMENTS umantis Single Sign On architecture is based on the SAML 2 standard and more specifically on the SAML Web Browser SSO Profile that is widely used on the Internet and specifically supported by Microsoft s ADFS technology. The SAML infrastructure defines two key components: the Service Provider (SP), for all practical purposes: the umantis cloud application, and the Identity Provider (IDP) which is responsible for checking credentials and authorizing access to protected resources. SP Browser IDP 1. Access Resource 2. Not signed in - redirect to SSO 2. Request SSO Service 3. Authenticate 4. Authentication Response 5. Success - redirect to Resource 5. Success - redirect to Resource 1. A user interacting via a web browser, attempts to access a resource on the SP 2. The SP determines that a session has not yet been initiated and redirects the user to the IDP for authentication. 3. The IDP request an authentication (e.g. login page) from the user 4. The user provides authentication (e.g. user & password) 5. The IDP authorizes the user and allows the SP to establish a session 4
umantis provides a default IDP for conventional logins where requested user and password credentials are checked against a database managed within its internal infrastructure. Some customers request a tighter integration into their internal working environment so that their existing domain credentials may be used to authorize access to their umantis solution without having to manage a separate set of user and passwords. umantis supports this scenario with its Cloud SSO. 5
CLOUD ADFS-BASED SSO Cloud SSO is rather straightforward as long as the customer can provide his own SAML2-capable Identity Provider. CUSTOMER-PROVIDED IDP: ADFS Where customers already have an Active Directory backed windows domain, the most common configuration involves the usage of Microsoft s ADFS component which is basically a lightweight service that extends Active Directory to make it SAML2-capable. NOTE: ADFS versions older than 2.0 are not supported UMANTIS SERVICE PROVIDER umantis applications are already SAML2-enabled by default, i.e. they are standard SAML Service Providers. CIRCLE OF TRUST A secure SSO configuration requires the SP and the IDP to know of each other, in such a way that they can ascertain that the counterparty is legitimate. In SAML, this is achieved by configuring a CIRCLE OF TRUST that involves exchanging metadata, signing and encryption certificates that ensure mutual authentication as well as the confidentiality of exchanged data. 6
ADFS SSO CONFIGURATION INSTRUCTIONS This section describes the precise elements that umantis and the customer must exchange as well as the configuration the customer must perform on their Active Directory Federation Server in order to establish the Circle of Trust required for Cloud SSO: SEND ADFS METADATA TO UMANTIS Option 1) send the ADFS metadata url to your ADFS metadata to umantis, typically: https://your_adfs_host_name/federationmetadata/2007-06/federationmetadata.xml Option 2) if the ADFS metadata url is not accessible from the Internet, load it in a browser by yourself, save it to a local file named idp.xml and send that file to umantis. ADD ADFS RELYING PARTY 1. Wait for umantis confirmation that your metadata has been activated. You will receive the umantisspentityid and umantisspmetaalias parameters that are required in the following steps in the confirmation email. 2. Use the ADFS 2.0 Management tool. 3. Navigate to Trust Relationships / Relying Party 4. Use the Add Relying Party Trust function to import the umantis service provider using the online url: For customers hosted in Switzerland: https://sso.umantis.com/multitenant-sp/saml2/metadata?metaalias=umantisspmetaalias For customers hosted in Germany: https://sso.de.umantis.com/multitenant-sp/saml2/metadata?metaalias=umantisspmetaalias Note: if no access from the ADFS server to the umantis server is possible, you may save the XML returned from the above url in any workstation and manually import it in ADFS. The following steps remain unchanged. 5. Ignore the warning that not all data could be imported 6. When asked whether you want to add Claim Rules select Yes to enter the Edit Claim Rules dialog. 7
7. Add a generic LDAP rule where you map the internal Active Directory LDAP attribute SAMAccountName (or any other attribute containing an existing umantis login such as E-Mail-Addresses) to the outgoing claim type UPN a. On the Issuance Transform Rules tab, click Add Rule. b. On the Select Rule Template page, select Send LDAP Attributes as Claims. Click Next. c. On the Configure Rule page, type the name of the claim rule in the Claim rule name field. d. From the Attribute Store drop-down list, select Active Directory. e. In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select SAMAccount or E-Mail- Addresses or any other suitable unique identifier that maps to existing umantis Talent Management account names. f. Under Outgoing Claim Type, select UPN. g. Click Finish, and then click OK. 8. Create an additional Custom Rule with the following definition: c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.issuer, OriginalIssuer = c.originalissuer, Value = c.value, ValueType = c.valuetype, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:saml:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "youradfsentityid", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "umantisspentityid"); Where: - youradfsentityid is usually of the form: http://your_adfs_host_name/adfs/services/trust - umantisspentityid is provided to you in Step 1 9. After importing the metadata, open the Settings dialog and: a. On the Encryption Tab, check that the umantis_te Certificate is selected. b. On the Signature Tab, check that the umantis_ts Certificate is selected. c. On the Advanced Tab, change the security algorithm to SHA1 8
VALIDATE CONFIGURATION Wait for umantis activation confirmation and point your browser to: For customers hosted in Switzerland: https://sso.umantis.com/multitenant-sp/saml2/spinitiatedsso? metaalias=umantisspmetaalias&redirect_uri=http://www.umantis.com For customers hosted in Germany: https://sso.de.umantis.com/multitenant-sp/saml2/spinitiatedsso? metaalias=umantisspmetaalias&redirect_uri=http://www.umantis.com If you were previously logged in as a Windows domain user you should be automatically redirected to the umantis web site; otherwise this will only happen after successfully supplying your credentials in the Domain Login window that should appear. The address bar should have a url of the following form: http://www.umantis.com/?loginparam= 9
ADDITIONAL CONFIGURATION Beyond the core Cloud SSO configuration described above, more advanced parameters may also be configured by umantis staff to satisfy customer requirements. IP-selective Cloud SSO, for instance, can be configured to precisely determine which IP address ranges (subnets) should participate in Cloud SSO. Advanced SAML2 parameters may also be tweaked to satisfy customerspecific requirements. However, this type of configuration requires a deep understanding of SAML2 and is beyond the scope of this document. Should the need arise; requirements of this nature will be reviewed by a technical expert. 10
FINALLY Once the configuration has been validated, SSO must be activated by umantis on the customer solution. Note: once activated, all logins will be handled by SSO by default (unless IP-Selective SSO has been configured). However, it is possible to force an non-sso login appending the following parameter to a umantis URL: https://some_umantis_url&v4login=1 11