Here I will outline the current process & steps for setting up single sign-on with your corporate identity provider (active directory) using ADFS (active directory federation services).

 

SAP BusinessObjects Cloud supports SAML2.0, and should work with any identity provider capable of supporting this standard.

 

Step 1.   Retrieve metadata from your Active Directory

Browse to https://<SERVER>/FederationMetadata/2007-06/FederationMetadata.xml  where <server> will be the server where ADFS is installed.

Your browser will download/open an XML file.

 

Step 2.  Download the Service Provider metadata from BusinessObjects Cloud, & upload the metadata from step #1, by following the below document:

https://help.sap.com/http.svc/rc/00f68c2e08b941f081002fd3691d86a7/release/en-US/3651184dad944aa2b361ad029a7a8cae.html

Step 4.  Configure Active Directory

The majority of work is on the ADFS side.  For details on AD setup, refer to Active directory Follow these steps:

 

  1. Add Relying Party Trusts
    1. Open AD FS 2.0 Management
    2. Expand AD FS 2.0 -> Trust Relationships
    3. Right click Relying Party Trusts, choose Add Relying Party Trust
    4. In Welcome step, click start
    5. In Select Data Source step, select Import data about relying party from a file, click Browse to select the metadata file  you received from SAP, click Next
    6. In Specify Display Name step, Input the Display name (such as “SAP BusinessObjects Cloud) and Notes, click Next
    7. In Choose Issuance Authorization Rules step, choose Permit all users to access this relying party, click Next
      1. To understand difference between permit all & deny see MS documentation.
    8. In Ready to Add Trust step, review all the information, then click Next
    9. In Finish step, click Close
  2. Change properties of the relying party trust
    1. Double click the relying party trust that you have just added to open the properties dialog
    2. In Advanced tab, Change the Secure Hash algorithm to SHA-1
      1. Note:  This will be changed to SHA-256 in the near future, this blog will be updated accordingly.
    3. Click OK
      image2015-11-4 17_18_52.png
  3. (Optional) Configure SAML logout page.  This sets where you want the users to be redirected when they click “logout” from the application.    You can redirect them to your corporate home page for example.
    – Note that redirecting them to the application logon page probably won’t make sense as that would redirect the user back to the SAML logon provider and start the logon workflow again.

 

    1. Expand AD FS 2.0 -> Trust Relationships -> Relying Party Trusts
    2. Double click your trust to open the properties dialog
    3. Click the Endpoints tab
    4. Select the SAML Logout Endpoints, and click Edit button
    5. Input the Response URL, then click OK to save the changes
      The response URL is suggested to be https://<server>/sap/fpa/ui/public/formLogin/
    6. Click OK to close the properties dialog
      image2015-11-4 17_21_17.png

4.  Setup which value will be used as the user mapping by editing Claim Rules.  For example username, or email.

    1. Expand AD FS 2.0 -> Trust Relationships -> Claim Provider Trusts
    2. Right click the provider that you will use to edit the claim rules of relying party trust, select Edit Claim Rules
    3. In Acceptance Transform Rules tab, click Add Rule
    4. In Choose Rule Type step, select Send LDAP Attributes as Claims, click Next
    5. In Configure Claim Rule step, input the claim rule name, select Active Directory as Attribute store, map the LDAP Attribute SAM-Account-Name to Outing Claim Type (here we use UserID as an example, you can specify yours )
      image2015-11-4 172339.png
    6. Click Finish to close Add Transform Claim Rule Wizard
    7. Click OK to close the Edit Claim Rules for Active Directory dialog

5. Edit Claim Rules of Relying Party Trust

  1. Expand AD FS 2.0 -> Trust Relationships -> Relying Party Trusts
  2. Right click the trust that you just added, select Edit Claim Rules
  3. In Issuance Transform Rules tab, click Add Rule
  4. In Choose Rule Type step, select Transform an Incoming Claim, then click Next
  5. In Configure Claim Rule step, input Claim Rule name, input the name you specify as Outing Claim Type in Claim Rules of Claim Provider Trust (Here we use UserID) for Incoming claim Type, select Name ID as Outgoing claim type, select Unspecified as Outing name ID format, select Pass through all claim rules, then click Finishimage2015-11-4 17257.png
  6. Click OK to close Edit Claim Rules dialog

6. Edit SAML user attributes, this will allow to pull in additional information.  Not all of it is required, if you don’t want to pull in phone numbers for example.

  1. Expand AD FS 2.0 -> Trust Relationships -> Relying Party Trusts
  2. Right click your trust, select Edit Claim Rules
  3. In Issuance Transform Rules tab, click Add Rule
  4. In Choose Rule Type step, select Send LDAP Attributes as Claims, then click Next
  5. In Configure Claim Rule step, input Claim Rule name, select Active Directory as Attribute store, map all the LDAP Attributes to the names you want, then click Finish

    The Mapping is suggested to be

    LDAP Attribute Outgoing Claim Type
    SAM-Account-Name ID
    SAM-Account-Name USERNAME
    Given-Name FIRST_NAME
    Surname LAST_NAME
    Display-Name DISPLAY_NAME
    E-Mail-Address EMAIL
    Telephone-Number OFFICE_PHONE
    Company COMPANY
    Street-Address OFFICE_ADDRESS
    Title JOB_TITLE
    mobile MOBILE
  6. Click OK to close Edit Claim Rules dialog

 

5. Step 5: Add users into the cloud system

Add users in the administration console with the appropriate SAML mappings.  If a user is not mapped in, they will get a 403 access denied when logging on.

/wp-content/uploads/2016/06/usermap_972728.png

In the above step, the AD user ID is used.  To use email, you would change the LDAP attribute mappings above into the example below, would insert the “email” value from active directory as the ID attribute of the SAML assertion received.

/wp-content/uploads/2016/06/samlmap_972730.png

6.   Step 6 Test the logon.

You will have received the logon URL setup for SAML as part of the SAP BCP ticket.  Users should now be able to logon via SAML.

 

Troubleshooting

  • Upon logon user gets an error “StatusCode in ResponseMessage != OK; please refer to the database trace for more information
    • Most likely because of the mismatch in SHA-1 to SHA-256.  In Step 4 above, confirm point #2 around secure hash algorithm.
    • Another likely scenario is that the SAML User Mapping has not been entered.  This would normally be the AD user ID, which is entered in Step 5 above.
  • Users are not getting redirected to the ADFS logon page
    • Confirm the logon URL.   It will have a pattern such as https://<server>/t/#    where # is the internal representation of your tenant ID.
    • You can also find the ID in the administration console
      /wp-content/uploads/2016/06/tenantinfo_972729.png
      in this example, my logon URL would be https://<server>/t/T
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Nelis Lamprecht

    If they can support SAML natively in the cloud with Business Objects then they should be able to support it in the standard on premises edition too ?! Hopefully soon.

    (0) 

Leave a Reply