

Logging in to Office365 with WS-Federation¶

This topic provides instructions on how to configure and federate the Office365 Passive STS client for single sign-on, based on the WS-Federation protocol, through the MWARE IAM. The following sections guide you through the entire process.

Configuring Azure Active Directory to Trust MWARE IAM
Configuring Office 365 WS-Federation with Identity Server

Configuring Azure Active Directory to Trust MWARE IAM¶

This section provides instructions on how to configure the Azure Active Directory to trust the on-premise IdP (the MWARE IAM) as the first part of the process of configuring WS-Federation with Office 365.

Prerequisites¶

Office 365 Business Account with access to the Admin Portal
An internet-resolvable domain name (Office 365 SSO requires each user's username to have an Internet-resolvable domain name as the suffix. You cannot federate the default domain that is provided by Microsoft that ends with "onmicrosoft.com")
A Windows Platform with Windows Azure Active Directory Powershell installed
MWARE IAM 5.1.0 or a later version

Configuring Azure AD¶

Start the Windows Azure Active Directory Powershell.
The following commands connect with Windows Azure AD Powershell.
1. This command prompts user credentials.
```
Run $cred=Get-Credential
```
  Tip
  
  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.
2. This command connects with the stored credentials. Provided that the credentials are accurate, the connection will be successful.
```
Connect-MsolService -Credential $cred
```
3. 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’.
```
Get-MsolDomain
```
Configure the domain as a federated domain, providing respective federation settings that match the IdP. Store the following federation settings in parameters. Replace the values below with your own.
- Store your domain
```
$dom = "wso2test.com"
$brandname = "wso2"
```
- Set the Issuer Id of the IdP. This value should be the same as the Identity Provider Entity Id in the Resident IDP of WSO2 Identity server.
```
$issuerUri = "https://wso2test.com"
```
- Set the Passive STS Endpoint URL of the IdP. This should be the Passive STS endpoint of the MWARE IAM.
```
$passiveLogonUri = "https://wso2test.com/passivests"
```
  Note
  
  If you will be configuring Office365 Active STS clients (complying with the WS-Trust protocol) through MWARE IAM as well, you can do the following configuration along with these configurations.
  
  Set the Active STS Endpoint URL of the IdP. This should be the Security Token Service endpoint of the WSO2 Identity server. Note that this endpoint is specific to WS-Trust and will not be used for the Passive STS use case.
```
$activeLogonUri="https://wso2test.com/services/wso2carbon-sts.wso2carbon-stsHttpsSoap12Endpoint"
```
- Set the MetaData Exchange endpoint URL of the IdP.
```
 $mex = "https://wso2test.com/services/mex-ut"
```
- Store the IdP Certificate. Base64 encoded signing certificate of MWARE IAM should be given here. For default keystore configured in MWARE IAM certificate is as below.
  
  Note
  
  The certificate should be given in a single line without a break.
```
$cert = "MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UEAwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTousMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQIDAQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44iQlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJRO4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo="
```

Run the following command to establish the trust.

Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -ActiveLogOnUri $activeLogonUri -IssuerUri $issuerUri -SigningCertificate $cert -LogOffUri $passiveLogonUri -FederationBrandName $brandname -MetadataExchangeUri $mex -PassiveLogOnUri $passiveLogonUri -PreferredAuthenticationProtocol WsFed

Run the following command to verify the federation settings
```
Get-MsolDomainFederationSettings -Domain $domain
```

Info

You have now successfully configured the Azure Active Directory to trust our on-premises IdP (MWARE IAM). For the next part of the process of configuring WS-Federation with Office 365, see Configuring Office 365 WS-Federation with Identity Server.

Configuring Office 365 WS-Federation with Identity Server¶

This section provides instructions on configuring the WSO2 Identity Server for WS-Federation with Office 365. The following sections guide you through this process.

Prerequisites¶

Configure Azure Active Directory (AD) to trust MWARE IAM. For more information on how to do this, see Configuring Azure Active Directory toTrust WSO2 Identity Server.
Configure an Active Directory user store as the primary user store in MWARE IAM. For more information on how to do this, see Configuring a Read-write Active Directory User Store.
Configure MWARE IAM to authenticate users using the email address as the username. For more information on how to do this, see Using Email Address as the Username.

Azure AD expects to receive the following attributes with a SAML 2.0 message.

Claim	Claim URI	Purpose
UserPrincipal	http://schemas.xmlsoap.org/claims/UPN	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 ). Since this attribute requires an email address as the username, make sure you have configured the IS to authenticate users using the email address. See Using Email Address as the Username for more information.
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

Start the MWARE IAM and log in to the management console
Click Resident under Identity Providers on the Main menu. 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 deselect the Supported by Default check box.

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 receive 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
http://schemas.xmlsoap.org/claims/UPN	http://wso2.org/claims/upn	Ticked (True)
http://schemas.microsoft.com/ws/2008/06/identity/claims/role	http://wso2.org/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
- If you are configuring the secondary user store, select Return objectGUID in UUID Canonical Format that is under the Advanced configuration when creating a new user store using the management console.
- If you are configuring the primary user store and want the configuration to be available for all the tenants, follow the configuration given below to return the objectGUID claim attribute.
  ObjectGUID is a binary attribute. Add the following user store property to the <IS_HOME>/repository/conf/deployment.toml file.
```
``` java
<Property name="transformObjectGUIDToUUID">false</Property>
```
```

Testing Office 365 WS-Federation with MWARE IAM¶

WS-Federation eliminates the need to send passwords between Active Directory and Office 365, but it still requires synchronizing the user accounts with Azure AD. You can do this manually or you can automate the process.

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.
1. This command prompts user credentials.
```
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.
2. This command connects with the stored credentials. Provided that the credentials are accurate, the connection will be successful.
```
Connect-MsolService -Credential $cred
```
3. 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’.
```
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.
```
New-MsolUser -UserPrincipalName wso2@wso2test.com -ImmutableID eDONEoBWe0SatxWqbZYobw== -LastName test -FirstName wso2 -DisplayName "WSO2 Test User"
```

You can now attempt to login to the Office365 Web Portal with this user you created. The user’s identity will be represented and authenticated by the on premises identity provider (i.e., the MWARE IAM).

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 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 MWARE IAM will receive a Passive STS Logout Request and the user will be logged out of the IdP as well.

Top