This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Logging in to Office365 with WS-Trust

The WSO2 Identity Server allows you to configure and federate the Office365 Active STS client (based on the WS-Trust protocol) for single sign-on. The WSO2 IS supports the following Office365 Active STS clients.
  • Skype for Business Desktop Client (Lync) 

  • Skype for Business Mobile client

  • OneDrive  for Desktop Business client

These Office365 Active STS clients send two types of requests to the WSO2 identity provider during the authentication process.

  • Metadata Exchange (MEX)
  • Secure Token Service Request (STS)  

Metadata Exchange

Clients such as Skype for Business and OneDrive use the WS-Metadata exchange specification, which is basically a service endpoint that exposes metadata about the service. As the first step of the authentication process, the Active STS client sends a Metadata request to the WSO2 Identity provider. The MetadataExchange service endpoint is shipped with WSO2 Identity Server to cater to the authentication requirements of the Office365 active clients. For more information on understanding WS-MetaData Exchange, see the following article

Secure Token Service (STS)

In simple terms, the client expects a security token from the users who are attempting to login using the WSO2 Identity Server. If the client demands or expects a secure token, the WSO2 IS needs to request and fetch the corresponding security token from a Secure Token Service. To do this, the Secure Token Service specification is used.  

This topic provides instructions on how to configure and federate the Office365 Active STS client for single sign-on, based on the WS-Trust protocol, through the WSO2 Identity server. The following sections guide you through the entire process.  

Prerequisites

Configuring Office 365 WS-Trust 

  1. Start the WSO2 Identity Server and log in to the management console

  2. Click Resident under Identity Providers in the Main menu. Expand the Inbound Authentication Configuration section and then the WS-Federation(Passive) Configuration.

  3. Replace the value of the Identity Provider Entity Id with the value given for the parameter $issueruri when configuring Azure AD (configured in step 3 of /wiki/spaces/IS570/pages/38176703) , and click Update to save changes.
    In this sample scenario, the value for the Identity Provider Entity Id is https://wso2test.com.

  4. Navigate to Claims>Add in the Main menu and click Add New Claim. Set 'User Principle' and 'ImmutableID' as claims as seen below. See Adding Claim Mapping for more information. 

  5. Navigate to Claims>List and click on the http://wso2.org/claims claim dialect. Click on Edit for each of the claims below and untick the Supported by Default checkbox. 

    Why do these claims need to be edited?

    These attributes are not supported by Active Directory by default. Therefore if these attributes are ticked as Supported by Default in Identity Server, they will be shown in the default user profile and you will recieve an error once you try to update the user profile.

  1. Navigate to  Service Providers > Add in the Main menu  and add a new Service Provider named ' Office365'. 

  2. Expand the   Inbound Authentication Configuration   section, then the   WS-Trust Security Token Service Configuration  and click Configure

  3. Enter the following details in the form that appears and click Apply. See Configuring WS-Trust Security Token Service  for more information about these fields. 

  4. Expand the Claim Configuration section and configure the following attributes required by Azure AD as seen below. 

     

  5. Set the Subject Claim URI to the Immutable ID claim and the Role Claim URI to the role claim. Click Update to save changes to the service provider. 

  6. Click Resident under Identity Providers  in the  Main  menu.  Expand the  Inbound Authentication Configuration  section, then the Security Token Service Configuration section and click Apply Security Policy

  7. Select Y es  in the Enable Security dropdown. 

  8. Select UsernameToken  under Basic Scenarios and click Next .


  9. Select the Admin  role checkbox from the User Groups and click Finish

    Note:   It is not mandatory to select the ‘admin’ role for authentication of the UserNameToken. Any role having ‘login’ permissions would be sufficient.

  10. Click Update to save all changes. 

  11. Create a user and update the user's profile with a User Principle Name as seen below.

    ObjectGUID is a binary attribute. Add the following user store property to the <IS_HOME>/repository/conf/user-mgt.xml file under the relevant user store tag in order to see the value properly in the management console.

    <UserStoreManager ... >
    ...
    <Property name="java.naming.ldap.attributes.binary">objectGUID</Property>
    ...
    </UserStoreManager>

Testing Office365 WS-Trust with WSO2 IS 

The Skype for Business client  is used to demonstrate testing of this scenario. You can test it with the user you created above. The user’s identity will be represented and authenticated by the on premises identity provider (i.e., the WSO2 Identity Server). 

  1. Download and install the Skype for Business client .
  2. Enter the email address of the user you created as the Sign-in address and enter the password of the user. 
  3. Click Sign In. The identity will be authenticated by the WSO2 IS and you will be successfully signed in to the Skype client. 
 Click here to troubleshoot

You might receive the following login error while you are trying to sign in to the Skype for Business client. This usually happens due to a DNS resolving issue.


This issue can be resolved by manually configuring DNS settings of the Skype for Business client itself.

  1. In the Skype for Business client, navigate to Options > Personal > Advanced > Manual configuration.
  2. Use the following value for both internal and external server.  

    sipdir.online.lync.com:443

  3. Save and try logging in again. Now you should be able to login successfully.