Federated Authentication 1 Introduction In order to improve security while streamlining access to Field Service Management applications, SAP Field Service Management has integrated Federated Authorization using SAML 2.0 and Microsoft Active Directory. This provides users with Single Sign-on access to all Field Service Management applications while protecting sensitive account information. Note: In addition to Microsoft Active Directory, SAP Field Service Management also supports any SAML-compliant Identity Provider for Federated Authentication. 2 Federated Authentication Overview This section provides an overview of the components involved in Federated Authentication, and how they relate to another. Fed Auth Overview 2.1 Federated Authentication 2.2 The Role of SAML 2.0 2.3 The Role of Microsoft Active Directory 2.4 All Parts Together 2.1 Federated Authentication Federated Authentication is an access control property that enables users to log in with a single a set of login credentials for all Field Service Management applications–without having to create different login credentials and profiles for each application. Federated Authentication in SAP Field Service Management applications is accomplished by using Security Assertion Markup Language 2.0 (SAML) to authenticate and authorize application access through tokens, with Microsoft Active Directory (AD) serving as the identity provider that mediates authentication and authorization between SAP FSM and Field Service Management users. More importantly this is acheived without SAP storing or validating user credentials. 2.2 The Role of SAML 2.0 SAML is an XML-based, open standard data format that uses security tokens to exchange authentication and authorization data about a Principal between Identity Providers and Service Providers. The SAML 2.0 specification defines three roles: the Principal, the Identity Provider, and the Service Provider. Name Acronym Equivalent Prinicipal Field Service Management user Service Provider SP Coresystems Identity Provider IdP Microsoft Active Directory or any other SAML-compliant Identity Provider A SAML 2.0 exchange in SAP Field Service Management apps takes the following course: The Field Service Management user requests a service from SAP FSM. SAP FSM requests and obtains an identity assertion token from the Active Directory server. On the basis of this identity assertion token, SAP can then make an access control decision to permit or deny service or resource access to the connected user. At the heart of the above exchange is the request exchange that occurs between SAP FSM and the Identity Provider. 2.3 The Role of Microsoft Active Directory The Identity Provider (Active Directory or another SAML-compliant server) authenticates the user through the standard means in Active Directory Domain Services and then issues a token containing a series of claims about the user, including the user’s identity. The Service Provider then validates the token and issues another token for the local servers to accept the claimed identity. This allows us to provide controlled access to resources/services to a user that belongs to another security realm without requiring the user to authenticate directly to the system without the two systems sharing a database of user identities or passwords. 2.4 All Parts Together The following sequence describes how all components interact with each other: A user opens the Field Service Management application and enters their credentials. The application asks for a token for the given account and user name. As the user is configured to log in via the 3rd party Identity Provider, the cloud authorization server replies with a redirect directive for the IdP’s SSO login page. Client application uses a browser (or any other user agent capable of handling html pages and user inputs) to open the IdP’s SSO login service. User authenticates him/herself against the SSO service. The Identity Provider sends an HTTP response with a redirect to the cloud’s assertion, including the SAML 2.0 assertion. The browser follows the redirect and navigates back to the cloud’s authorization server with the SAML 2.0 assertion as a parameter. The authorization server verifies the SAML assertion and extracts user details. In case the given user does not exist in the cloud and just-in-time user provisioning is configured, cloud creates a new cloud user and maps him to the federated identity received in the SAML assertion. When the user is correctly authorized, the authorization server can issue an OAuth token. The User requests a cloud service (i.e. Synchronization, Data API call, etc.) The application adds the OAuth token to the call and requests the resource from the cloud’s resource server. The resource is returned to the client. 3 Configure the Cloud Account in the Admin portal Please note the following: SAML is configured by default for ALL accounts SAML is configured by default for ALL users The steps contained in this section are only required for accounts for which SAML is not automatically enabled. 3.1 Add New SAML Configuration In the Admin portal open the account details, click on SAML menu entry on the left, click on Create. Fill the form as follows: Field Description Name Input a name for the new SAML configuration. Identity Provider Metadata URL Here you will set the URL for the Identity Provider’s metadata (example: https://corp.dev.coresuite.com/FederationMetadata/2007-06/FederationMetadata.xml). Issuer This is found in the metadata XML with xpath: /EntityDescriptor/@entityID Login URL This is located in the metadata XML with xpath: /EntityDescriptor/IDPSSODescriptor/SingleSignOnService[@Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"]/@Location Identity Provider Signing Certificate to be found in the metadata xml with xpath: /EntityDescriptor/IDPSSODescriptor/KeyDescriptor[@use="signing"]/KeyInfo/X509Data/X509Certificate/text() Click Save. 3.2 Configure Account’s Default Authentication Method This setting ensures that all new users of the account will use the specified authentication method. In the Admin portal open the account details, click on Edit to edit the account details Set Default SAML Configuration to your created SAML configuration. Click Save. 3.3 Configure User’s Authentication A user can log in either via password (by default) or via SAML. In order to ensure that the user logins in via SAML, complete the following steps: Open User Detail and click Edit Choose SAML Configuration Click Save. 4 Configuring Your IDP 4.1 Name ID Tag Required NameID attribute should be the Email of the User. 4.2 Sample Configurations 4.2.1 SAP IAS SAML 2.0 Please refer to the following guide if you are integrating with SAP IAS SAML 2.0. 4.2.2 Microsoft ADFS Please refer to the following guide if you are integrating with Microsft ADFS 5 Post-Configuration 5.1 Web App Login After entering the cloud account name on login, users will be directed to the external login page. If SAML has NOT been configured for the user, they can still login directly to the application using their cloud credentials using the following url: https://apps.coresystems.net/workforce-management/#/login/password/ If SAML has been configured for the user, they are always directed to the external login page. 5.2 Mobile App Login After entering the cloud account name on login, users will be directed to the external login page. In order to login with username and password, users that are member of an account that uses SAML by default must enter their e-mail address instead of the account name in order to get to the username / password screen. If SAML is NOT configured for the user, they can directly login to the application with their cloud credentials. If the user has SAML configured, they will be directed to the external login page.