This section provides instructions on configuring the WSO2 Identity Server for WS-Federation with Office 365. The following sections guide you through this process.
...
Azure AD expects to receive the following attributes with a SAML 2.0 message.
Claim | Claim URI | Purpose | ||
---|---|---|---|---|
UserPrincipal | This must be the email address of the Office365 user. Usually this is the userPrincipalName attribute in AD. Basically this is the login username that a user tries out to login for Office365. It should match with the domain name. (ex: wso2@wso2test.com).
| |||
ImmutableID | http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID | This is the Immutable ID that is set by the Azure AD sync service out of the box. If you use a different value, then this claim must be populated with that value for each user. So in this case we will use the ObjectGUID attribute in AD which is unique per user | ||
Role | http://schemas.microsoft.com/ws/2008/06/identity/claims/role | The URI for a claim that specifies the role of a Windows user |
Configuring Office 365 WS-Federation
Start the WSO2 Identity Server and log in to the management console
Navigate to the Identity Providers>List in the Main menu and click Resident Identity Provider. Expand the Inbound Authentication Configuration section and then the WS-Federation(Passive) Configuration.
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 this topic) , and click Update to save changes.
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.
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.
Info title 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.
Country - http://wso2.org/claims/country
- Organization - http://wso2.org/claims/organization
- IM - http://wso2.org/claims/im
Navigate to Service Providers > Add in the Main menu and add a new Service Provider named ' Office365'.
Expand the Inbound Authentication Configuration section, then the WS-Federation(Passive) Configuration and enter the following details. See Configuring WS-Federation Single Sign-On for more information about these fields.
- Passive STS Realm - urn:federation:MicrosoftOnline
- Passive STS WReply URL - https://login.microsoftonline.com/login.srf
Expand the Claim Configuration section and configure the following attributes required by Azure AD as seen below.
Service Provider Claim Local Claim Requested Claim Ticked (True)
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
Ticked (True)
http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
http://wso2.org/claims/objectguid Ticked (True) - Set the Subject Claim URI to the Immutable ID claim and the Role Claim URI to the role claim. Click Update to save changes.
Create a user and update the user's profile with a User Principle Name as seen below.
Note 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.Code Block <UserStoreManager ... > ... <Property name="java.naming.ldap.attributes.binary">objectGUID</Property> ... </UserStoreManager>
...
- Manually - Add Office 365 users that match each Active Directory user account
- Automate - Automate the process with the Microsoft Directory Synchronization Tool.
The following steps describe how to manually to synchronize a user with Azure AD.
- Connect with Windows Azure AD Powershell module by executing the following commands.
This command prompts user credentials.
Code Block language powershell Run $cred=Get-Credential
Info This will prompt for Windows Azure AD Admin credentials for the Office365 domain. The admin user’s domain credentials are usually in the following format: user@domain.onmicrosoft.com .
This command connects with the stored credentials. Provided that the credentials are accurate, the connection will be successful.
Code Block language powershell Connect-MsolService –Credential $cred
This command verifies the availability of the validated domain. This will return the Status and Authentication. The ‘Status’ of our domain should be ‘Verified’, and ‘Authentication’ should be ‘Managed’.
Code Block language powershell Get-MsolDomain
Run the following command to create a new user.
Note Use the value specified under objectGUID as -ImmutableId and the value specified under userPrincipalName, as the UserPrincipalName.
Code Block New-MsolUser -UserPrincipalName wso2@wso2test.com -ImmutableID eDONEoBWe0SatxWqbZYobw== -LastName test -FirstName wso2 -DisplayName "WSO2 Test User"
...
Access the following URL on your browser: https://login.microsoftonline.com/
Enter the username along with the federated domain following this format: wso2@wso2test.com
Info Note that this username is the same value specified as the the userPrincipleName.
You will be redirected to the login page of the WSO2 Identity Server’s authentication end point. Enter the correct user credentials and login.
You will be successfully logged on to the Office365 portal.
Info If you sign out of Office 365, the WSO2 IS will receive a Passive STS Logout Request and the user will be logged out of the IdP as well.