STS Integration Paper using WS-* Protocols

Introduction

This document is a guide for establishing and proving out the various aspects of a relying party trust between a WS-* compliant STS with Azure Active Directory (AAD). The intended audience for this is an identity provider vendor looking to have Office 365 tenants federate with their identity provider. Throughout this document this process will be referred to as "domain federation". The WS-* compliant STS is acting as an Identity Provider and Azure Active Directory is acting as a Relying Party. To aid in that process this document describes the following:

Details of the required token elements, how they are generated and associated restrictions.
A Sample of tokens generated by AD FS.
A Sample of the WSDL from AD FS MEX end point for reference.
A Sample of the response to a request from Exchange Online, including details of the specifics that Exchange send for location Isolation.
Test cases that cover the ongoing authentication and management/establishment of the trust itself.
PowerShell cmdlets that interact with the platform and the authentication system to establish and maintain the trust.
Order of operations when converting a domain from standard authentication to federated authentication.
Additional message flow details and sample messages for Office rich client authentication requirements.

Please note: it is responsibility of independent software vendors to validate compatibility of their implementation for the purpose of federating with Microsoft AAD. These independent software vendors are further responsible for providing customer support to their customers who run into problems after deploying their federated solutions with Microsoft AAD. Microsoft cannot provide claims of compatibility or customers support for these federated solutions.

Token Claim Requirements

There are number of specific items that the STS must send in the token and understand how these are interpreted to ensure a successful log on. This section describes those and the impact of each.

Issuer URI

The IssuerURI is used to by the authentication platform to locate the namespace that the token is designated for. For this reason this must be unique per namespace configured for federation. For example if contoso.co.uk and contoso.com are serviced by the same federation server they must both present different IssuerURIs. For example the issuer URIs could be:

http://contoso.co.uk/sts/services/trust;

and

http://contoso.com/sts/services/trust

NOTE that for domains such as contoso.com and sales.consoto.com where sales.contoso.com is registered as a sub domain within the tenant they can both be supported with a single IssuerURI.

Token Contents

The token is structured based on a SAML 1.1 token and contains two key elements that must be represented correctly to match the account provisioned in AAD.

Element

Description

Schema

ImmutableID

Unique Identifier of the user that must match the ImmutableID value configured on the user in AAD. The Windows Azure Active Directory Synchronization tool uses the AD ObjectGUID base 64 encoded by default.

This value is present in:

saml:AttributeStatement/saml:NameIdentifier
saml:Attribute[@AttributeName='ImmutableID']/saml:AttributeValue
saml:AuthenticationStatement/saml:Subject/saml:NameIdentifier

http://schemas.microsoft.com/OrgID/Federation/2008/05

UPN

User Principal Name of the user mapped to the AD UPN value. This value is present in

saml:Attribute[@AttributeName='UPN']/saml:AttributeValue

http://schemas.xmlsoap.org/claims/upn

Here is the URL for the Federation Meta Data for the Global Azure AD instance: https://nexus.microsoftonline-p.com/FederationMetaData/2007-06/federationmetadata.xml

Here is the URL for the Federation Meta Data for the in country China Azure AD instance: https://nexus.partner.microsoftonline-p.cn/FederationMetaData/2007-06/federationmetadata.xml

In the below samples it is required to take special note on the following which are taken from the federation metadata file federationmetadata.xml.

wsp:AppliesTo/wsa:EndpointReference/wsa:Address

Saml:Assertion/saml:Audience

Sample Token from a Passive Logon

<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2011-05-31T20:53:17.332Z <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2011-05-31T21:53:17.332Z <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> wsa:Addressurn:federation:MicrosoftOnline <t:RequestedSecurityToken> <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_0b4132be-c9e3-48d1-a6aa-2c6566bfc0e4" Issuer="urn:federation:Contoso" IssueInstant="2011-05-31T20:53:17.379Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2011-05-31T20:53:17.332Z" NotOnOrAfter="2011-05-31T21:53:17.332Z"> saml:AudienceRestrictionCondition saml:Audienceurn:federation:MicrosoftOnline saml:AttributeStatement saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">epQ6qbLW2E66X9AM0P3Cjg== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims"> saml:AttributeValue rossa@contoso.com <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05"> saml:AttributeValueepQ6qbLW2E66X9AM0P3Cjg== <saml:AuthenticationStatement AuthenticationMethod="urn:federation:authentication:windows" AuthenticationInstant="2011-05-31T20:53:17.161Z"> saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">epQ6qbLW2E66X9AM0P3Cjg== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ds:SignedInfo <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"> <ds:Reference URI="#_0b4132be-c9e3-48d1-a6aa-2c6566bfc0e4"> ds:Transforms <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"> ds:DigestValueJ/j38i9ES+DP4w+h4BKAn4BHnvY= ds:SignatureValueBO316ELBa2IlQWS/yg6GvzK6oTzJMVVwfBWSK1lte7642xMwDCWKUzOjfFmEACXKVzGIrix3hVbfbzsUB6CNVi7Itz0Cvdn5f6oY+aJplg9T2DGvHtLFDVtBN6bOKvpH2txLCsc97bvA3Mq/g1oAB+donLKeyhQCmkwExoZoCCywJ2gZvGo7m20iODGiD80Ac0MbutecNq9ag/Aef8xpEhUd6t8xYZ3x0k4LWStjPU4DDlAsGUqWZE89vgDG7svn1U8nOwaES3bjRl+aozbwG7U5t1qrNh7zyfVXa9ZR7KkznEoV5Pp9mJByiXk90WIMwB/pRQM/S3YrmuDV/WmM0Q== MIIC7DCCAdSgAwIBAgIQXqcbrpWrr7dC7GwDeZDkRjANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBTdHMuVFIxMi5vMzY1SWRlbnRpdHkudXMwHhcNMTEwMTI1MDUyNzIyWhcNMTIwMTI1MDUyNzIyWjAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBTdHMuVFIxMi5vMzY1SWRlbnRpdHkudXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0AZSqbWBYnlq0JgNQ6U7twq4jarvx3K7ZpIrkPqUskzlN5co7xMuyKAXzMnEYxQZAHvkZMlteppwPY67F42+1AK0kBW78E9rtlgb8mOzXtHMrBNaSJE68qOU /MYOBIKXUMrvsz87clzhYHlGP4e/IuqdIhzCValja5ARekJJf3pzilepdkzE055til6vOpnr9SW97E/BBvzPakSSUp2al2DnMQagcUMrTQEHtgkftOxD0NZo3lc92XEAu6i8O5V7Fp0tTn2sTbdHpVEb5kww5t/njenrwPzExb7ozymXcqXw30WZNvxQ5QqJ2cFm6NgOttqgls8S kzKZX88yo6au5AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAEOqRIKUZS4RoJ7+wDJUA5o9TSK6SLsGrGrp/Yfbu6f7/H7hjNy8fkSazQYQafQ3V2JzNtTwkcvmitlG+sXl8YKlkhNg5UyTJjX3Hot41EKhS4UxbmY8BSMJAy7/2C0vWOIZ8S17yKT6Yioaqx55lyOqJxd6m6n+f5qpmW++NUAMOzU/YZ4pP/73QUfFCbW7mr2JdAw5S8weXUW8xcpwc3jgxmFvjfHWiOUfAP6rO7ksEOSsl7kCEtsvJiTutSPJUOiuYGIECQLyt5zb8GkLME9ZAwhZRKB84bYW1S860tzNTyExYEzIclOIimJhzSJ41IVdUO5W/fYLl45Md7taTgY= <t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue <t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey

Sample Token from an Active Logon:

<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_112f2d65-c70c-4c7e-812a-e958e2ec5558" Issuer="urn:federation:Contoso" IssueInstant="2011-12-07T17:06:22.385Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2011-12-07T17:06:22.306Z" NotOnOrAfter="2011-12-07T18:06:22.306Z"> saml:AudienceRestrictionCondition saml:Audienceurn:federation:MicrosoftOnline saml:AttributeStatement saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">epQ6qbLW2E66X9AM0P3Cjg== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims"> saml:AttributeValue rossa@contoso.com <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05"> saml:AttributeValueepQ6qbLW2E66X9AM0P3Cjg== <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2011-12-07T17:06:22.306Z"> saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">epQ6qbLW2E66X9AM0P3Cjg== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ds:SignedInfo <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <ds:Reference URI="#_112f2d65-c70c-4c7e-812a-e958e2ec5558"> ds:Transforms <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /> ds:DigestValueougaXKPwRZSMECNAb9Sqw8XG6KE= ds:SignatureValuenh7gYzZtf5iop0POgG1kC3KDmelbMXG/2xxYZWW9pAphmA4vR+4G/o+64Z6HtYirRykqL6VZleUL25eRhN0XxXmvQPwv2TLEOPynWy8j3oMWEqz/Va7NkJsew/2I4Q0ibdn7WFQxfvmfZCmf4paaCDsGYztKj2bON52ole5Sc62tfe6N6jdOPPHTdDlpASv9CD4gT9dPY9wes6DJ7GcRf6VA6Nw4O53gp17FIQjeKNg8cXDgaPXvN2o2d/Lmj4p404/IQanHZqsIPo4HMSrGou2vQYYZYJQgkuZTLUMGxzdo+X4D7OMFdCOZPUWas7Aoi6H2kOfR5Mm1Ys8h8yi6qQ== MIIC7DCCAdSgAwIBAgIQXqcbrpWrr7dC7GwDeZDkRjANBgkqhkiG9w0BAQsFADAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBTdHMuVFIxMi5vMzY1SWRlbnRpdHkudXMwHhcNMTEwMTI1MDUyNzIyWhcNMTIwMTI1MDUyNzIyWjAyMTAwLgYDVQQDEydBREZTIFNpZ25pbmcgLSBTdHMuVFIxMi5vMzY1SWRlbnRpdHkudXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0AZSqbWBYnlq0JgNQ6U7twq4jarvx3K7ZpIrkPqUskzlN5co7xMuyKAXzMnEYxQZAHvkZMlteppwPY67F42+1AK0kBW78E9rtlgb8mOzXtHMrBNaSJE68qOU/MYOBIKXUMrvsz87clzhYHlGP4e/IuqdIhzCValja5ARekJJf3pzilepdkzE055til6vOpnr9SW97E/BBvzPakSSUp2al2DnMQagcUMrTQEHtgkftOxD0NZo3lc92XEAu6i8O5V7Fp0tTn2sTbdHpVEb5kww5t/njenrwPzExb7ozymXcqXw30WZNvxQ5QqJ2cFm6NgOttqgls8SkzKZX88yo6au5AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAEOqRIKUZS4RoJ7+wDJUA5o9TSK6SLsGrGrp/Yfbu6f7/H7hjNy8fkSazQYQafQ3V2JzNtTwkcvmitlG+sXl8YKlkhNg5UyTJjX3Hot41EKhS4UxbmY8BSMJAy7/2C0vWOIZ8S17yKT6Yioaqx55lyOqJxd6m6n+f5qpmW++NUAMOzU/YZ4pP/73QUfFCbW7mr2JdAw5S8weXUW8xcpwc3jgxmFvjfHWiOUfAP6rO7ksEOSsl7kCEtsvJiTutSPJUOiuYGIECQLyt5zb8GkLME9ZAwhZRKB84bYW1S860tzNTyExYEzIclOIimJhzSJ41IVdUO5W/fYLl45Md7taTgY=

Sample MEX end point:

The MEX document returned is a WSDL format document. Please pay special attention that the MEX response returned should contain correct UsernameMixed and Windowstransport information.

Client Access Policies for Location Isolation

Client Access Policies was added to ADFS to limit access to Office 365 services based on the location of the client. More details of this can be found in the article here.

This is implemented by allowing certain headers in the Exchange incoming token to be used in claim rules. These headers are detailed in the link above including the possible value set.

It is recommended that to aid the implementation that additional claims that represent if the token passed through a proxy or was destined for the passive end point vs the active endpoint. By adding such claims it is possible for clients to create rules to block access for specific scenarios per the link above.

Client End-Point Matrix

There are three different end points used by the various clients as follows:

End Point	Clients
Passive	All web clients including Office rich client apps connecting to SharePoint Online.
Active	Used exclusively by Exchange Online for Proxy Authentication. Outlook also uses this end authentication process.
MEX	Used by the Microsoft Online Sign In Assistant. Currently Lync Online, Various versions of Office, CRM Online and the Windows Azure Active Directory PowerShell Module use this end point.

The implementer of the third party STS should confirm that they are able to support all the end points correctly.

Customer Federation Setup

Generally the recommended order of operations is such that the customer should move to federation before any other operations (steps located here). However this is not always possible. In these cases the customer may need to perform other operations. Generally these are outside of the establishment of the trust but it is important to understand these. More details about this can be found in the online documentation here:

It is important to understand the variety of options and models customers have in their environments by reviewing this documentation. It is recommended that for any additional documentation created, it should enforce the same type of configuration.

NOTE: The Microsoft Connectivity Analyzer Tool can be downloaded and used to test your STS. Once you have configured an Azure AD tenant for federation with your STS, you can enter the login details for a user on that tenant and the tool will attempt to sign-in to your STS and provide the results of tests. The tool can be found here.

Establishing/Managing a Trust

There are four basic operations that must be supported by an STS provider when establishing a trust with AAD. These operations depend on the state of the domain that is being migrated and can be one of the following:

Greenfield. This is when a new domain is being added to a tenant and no existing foot print exists for this domain.
Conversion from Standard Auth to a Federation. When an existing domain is already associated with AAD and is converted from Standard (Cloud based authentication) to federated authentication.
Conversion from Federated Auth to Standard. When an existing domain is already associated with AAD and is converted from federation to Standard authentication.
Update of the relying party details. This is the process of updating an existing federated domain's properties such as certificates and the like.

Establishing single sign-on federation from Office 365 is detailed in the Single sign-on roadmap on Technet. Here is some additional important information when converting a domain to federation that should be considered as part of planning.

The operation occurs immediately and all users in the domain must log on using the federation severs. Thus converting to federation should be considered a big switch, if it is not setup properly then users will not be able to logon.
All sub domains of the root domain are also federated in the same action.
Note that users within the domain are not affected by the operation itself. Each user remains in a standard state and it converted to a federated sign-in user on the next login.
It is recommended that a standard authentication administrator account, for example an administrator in the *.onmicrosoft.com domain, be kept so that should federation fail for some reason there is an admin account that can be used to convert or fix the problem.

Similarly converting a domain back to Standard authentication has a number of considerations. You can read about this process on TechNet in the Convert-MsolDomainToStandard library article.

Domain conversion to standard authentication can take up to two hours to propagate through the service.
When a domain is converted back to standard authentication users who are set to federated authentication do not automatically change state and will be unable to sign-in until they are individually converted. Users that are in a federated state must be individually converted back to standard authentication users and given a new password. Note: Calling convert on a user that is already standard authentication will not reset the password, thus it can be called many times on the same user(s) without issue.
CAUTION: Domain conversion should only be used with extreme caution as all users may require a new password, it is not recommended that you convert a domain often but it can be safely used if initial federation fails.

Cmdlet Ordering

New Federated Domain

Order	Cmdlet	Purpose
1	Connect-MsolService	Establishes a connection to the Azure AD
2	New-MsolDomain	Adds a new domain to the tenant
3	Get-MsolDomainVerificationDns	Returns the DNS records needed for domain verification
4	Confirm-MsolDomain	Establishes ownership of the domain and completes the federation process, passing the necessary parameters.

Converting a Domain to Federation or Standard

Order	Cmdlet	Purpose
1	Connect-MsolService	Establishes a connection to the cloud
2	Set-MsolDomainAuthentication	Converts the domain based on the authentication setting.

Management of the trust

Order	Cmdlet	Purpose
1	Connect-MsolService	Establishes a connection to the cloud
2	Get-MsolDomainFederationSettings	Get the current federation settings
3	Set-MsolDomainFederationSettings	Update single or multiple properties on a federated domain, for example the signing certificate

Cmdlets Details

All cmdlets require that a connection be established through the connect-MsolService cmdlet. Once connected the session is shared between all of the calls. Both federated and standard credential can be used to connect. It is possible to use the currently logged on credentials for federated accounts by specifying the –CurrentCredentials switch. Below are the cmdlets and their purpose.

More information about these and other cmdlets can be found here: http://aka.ms/linkid9841481

New-MsolDomain

This cmdlets adds a new domain in an unverified state. When adding you will need to set the authentication type to federated. For example

New-MsolDomain -Authentication Federated -Name contoso.com

When a sub domain of an existing root domain is added the domain will automatically be verified and inherit the settings from the root domain no additional actions is required nor can any additional action be performed.

Get-MsolDomainVerificationDns

The cmdlet allow you to retrieve the DNS record required to verify domain ownership. For example:

Get-MsolDomainVerificationDns -DomainName contoso.com -Mode {DnsTxtRecord |DnsMXRecord }

TXT record is the preferred method.

Confirm-MsolDomain

Confirms domain owner ship and setups the federation trust with AAD. It is important that the following parameters are included.

Parameter	Description
ActiveLogOnUri	A URL that specifies the end point used by active clients when authenticating with domains set up for single sign-on (also known as identity federation).
DomainName	The fully qualified domain name (FQDN) to verify.
FederationBrandName	The name of the string value shown to users when signing in to AAD. We recommend that customers use something that is familiar to users, such as "Contoso, Inc."
IssuerUri	The unique identifier of the domain in the AAD identity platform that is derived from the federation server.
LogOffUri	The URL clients are redirected to when they sign out of AAD.
MetadataExchangeUri	The URL that specifies the metadata exchange end point used for authentication from rich client applications such as Lync Online.
NextSigningCertificate	The next token signing certificate that will be used to sign tokens when the primary signing certificate expires.
PassiveLogOnUri	The URL that web-based clients will be directed to when signing in to AAD.
SigningCertificate	The current certificate used to sign tokens passed to the AAD identity platform.
PreferredAuthenticationProtocol	Specifies the type of domain to federate. In this case WsFed to establish a Ws-* trust.

Set-MsolDomainAuthentication

This cmdlet allows for the conversion of the domain from Federated to Managed and Managed to Federated. Depending on the conversion process the calls will vary slightly.

Parameter	Description
Authentication	Specifies the authentication type, Federated or Managed. When the domain is being converted to Managed (aka Standard Authentication) this and the domain name are the only required parameter.
ActiveLogOnUri	A URL that specifies the end point used by active clients when authenticating with domains set up for single sign-on (also known as identity federation).
DomainName	The fully qualified domain name (FQDN) to verify.
FederationBrandName	The name of the string value shown to users when signing in to AAD. We recommend that customers use something that is familiar to users, such as "Contoso, Inc."
IssuerUri	The unique identifier of the domain in the AAD identity platform that is derived from the federation server.
LogOffUri	The URL clients are redirected to when they sign out of AAD.
MetadataExchangeUri	The URL that specifies the metadata exchange end point used for authentication from rich client applications such as Lync Online.
NextSigningCertificate	The next token signing certificate that will be used to sign tokens when the primary signing certificate expires.
PassiveLogOnUri	The URL that web-based clients will be directed to when signing in to AAD.
SigningCertificate	The current certificate used to sign tokens passed to the AAD identity platform.
PreferredAuthenticationProtocol	Specifies the type of domain to federate. In this case WsFed to establish a Ws-* trust.

Get-MsolDomainFederationSettings

This allows for the federation settings from Azure AD to be retrieved. Those settings reflect the same table as per the set below.

Set-MsolDomainFederationSettings

This allows for any parameter to be updated on the federated domain. For example this can be used to update the token signing certificates.

Parameter	Description
ActiveLogOnUri	A URL that specifies the end point used by active clients when authenticating with domains set up for single sign-on (also known as identity federation).
DomainName	The fully qualified domain name (FQDN) to verify.
FederationBrandName	The name of the string value shown to users when signing in to AAD. We recommend that customers use something that is familiar to users, such as "Contoso, Inc."
IssuerUri	The unique identifier of the domain in the AAD identity platform that is derived from the federation server.
LogOffUri	The URL clients are redirected to when they sign out of AAD.
MetadataExchangeUri	The URL that specifies the metadata exchange end point used for authentication from rich client applications such as Lync Online.
NextSigningCertificate	The next token signing certificate that will be used to sign tokens when the primary signing certificate expires.
PassiveLogOnUri	The URL that web-based clients will be directed to when signing in to AAD.
SigningCertificate	The current certificate used to sign tokens passed to the AAD identity platform.
PreferredAuthenticationProtocol	Specifies the type of domain to federate. In this case WsFed to establish a Ws-* trust.

Sample Values for Federation Settings

Below are some sample values for each of the properties and values.

Property	Value
ActiveLogOnUri	https://sts.demo.o365identity.us/adfs/services/trust/2005/usernamemixed
FederationBrandName	Identity Demo
IssuerUri	http://sts.demo.o365identity.us/adfs/services/trust
LogOffUri	https://sts.demo.o365identity.us/adfs/ls/
MetadataExchangeUri	https://sts.demo.o365identity.us/adfs/services/trust/mex
NextSigningCertificate
PassiveLogOnUri	https: //sts.demo.o365identity.us/adfs/ls/
SigningCertificate

Office Rich Client Protocol Flow

The following sections 5 and 6 include additional information that provides for interoperability with Office rich clients, in simple scenarios, where a user authenticates using a username and a password.

Figure 1 above shows the Office Rich client protocol flow.

As described in the flow a federating STS needs to support two endpoints. A MEX endpoint that allows for retrieval of Meta data (called out as MEX in the flow above), such as the URL's to the token endpoint. And a token endpoint to which the client makes a request security token request (with credentials such as username/password), which the STS responds with a security token response, returning the security token. These requests are generally SOAP requests.

Office Rich Client Sample Messages

Below are sample messages that describes the request and response of the MEX endpoint, and the request and response of the token endpoint. These were taken with an ADFS.

MEX Request and Response - POST

The client makes a SOAP request at the MEX endpoint to retrieve metadata about the STS. Examples of metadata include policies, signing certificates, endpoints etc. More information that describes the MEX endpoint can be found at http://technet.microsoft.com/en-us/library/adfs2-help-endpoints(v=WS.10).aspx

The MEX request is as follows:

POST https://corp.sts.microsoft.com/adfs/services/trust/mex HTTP/1.0 Connection: Keep-Alive Content-Type: application/soap+xml Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1; Win64; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MSOIDCRL 7.250.4422.0; MSOIDCRL-cfg 14.0.18476.0; App IdcrlUiClient.exe, 1.0.0.0, {FBDB95BC-BFCC-4433-80CC-534B08639C11}) Content-Length: 461 Host: corp.sts.microsoft.com

<s:Envelope xmlns:s=http://www.w3.org/2003/05/soap-envelope xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1"> http://schemas.xmlsoap.org/ws/2004/09/transfer/Get <a:MessageID>1386375951 <a:ReplyTo> <a:Address>http://www.w3.org/2005/08/addressing/anonymous <a:To s:mustUnderstand="1"> https://corp.sts.microsoft.com/adfs/services/trust/mex <s:Body/>

The MEX response is as follows:

HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Microsoft-HTTPAPI/2.0 Date: Sat, 07 Dec 2013 00:25:51 GMT Connection: close

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse <a:RelatesTo>1386375951 <s:Body> <wsx:MetadataSection Dialect="http://schemas.xmlsoap.org/wsdl/" Identifier="http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice" xmlns=""> <wsdl:definitions name="SecurityTokenService" targetNamespace="http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice" xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsa10="http://www.w3.org/2005/08/addressing"> <wsp:Policy wsu:Id="UserNameWSTrustBinding_IWSTrustFeb2005Async_policy"> wsp:ExactlyOne wsp:All <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> wsp:Policy sp:TransportToken wsp:Policy <sp:HttpsToken RequireClientCertificate="false"/> sp:AlgorithmSuite wsp:Policy sp:Basic256/ sp:Layout wsp:Policy sp:Strict/ sp:IncludeTimestamp/ <sp:SignedSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> wsp:Policy <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> wsp:Policy sp:WssUsernameToken10/ <sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> wsp:Policy <mssp:RsaToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never" wsp:Optional="true" xmlns:mssp="http://schemas.microsoft.com/ws/2005/07/securitypolicy"/> sp:SignedParts <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/> <sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> wsp:Policy sp:MustSupportRefKeyIdentifier/ sp:MustSupportRefIssuerSerial/ sp:MustSupportRefThumbprint/ sp:MustSupportRefEncryptedKey/ <sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> wsp:Policy sp:MustSupportIssuedTokens/ sp:RequireClientEntropy/ sp:RequireServerEntropy/ wsaw:UsingAddressing/ wsdl:types <xsd:schema targetNamespace="http://schemas.microsoft.com/ws/2008/06/identity/securitytokenservice/Imports"> <xsd:import namespace="http://schemas.microsoft.com/Message"/> <xsd:import namespace="http://schemas.xmlsoap.org/ws/2005/02/trust"/> <xsd:import namespace="http://docs.oasis-open.org/ws-sx/ws-trust/200512"/> <wsdl:message name="IWSTrustFeb2005Async_TrustFeb2005IssueAsync_InputMessage"> <wsdl:part name="request" element="t:RequestSecurityToken"/> <wsdl:message name="IWSTrustFeb2005Async_TrustFeb2005IssueAsync_OutputMessage"> <wsdl:part name="TrustFeb2005IssueAsyncResult" element="t:RequestSecurityTokenResponse"/> <wsdl:portType name="IWSTrustFeb2005Async"> <wsdl:operation name="TrustFeb2005IssueAsync"> <wsdl:input wsaw:Action="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue" message="tns:IWSTrustFeb2005Async_TrustFeb2005IssueAsync_InputMessage"/> <wsdl:output wsaw:Action="http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue" message="tns:IWSTrustFeb2005Async_TrustFeb2005IssueAsync_OutputMessage"/> <wsdl:binding name="UserNameWSTrustBinding_IWSTrustFeb2005Async" type="tns:IWSTrustFeb2005Async"> <wsp:PolicyReference URI="#UserNameWSTrustBinding_IWSTrustFeb2005Async_policy"/> <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="TrustFeb2005IssueAsync"> <soap12:operation soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue" style="document"/> wsdl:input <soap12:body use="literal"/> wsdl:output <soap12:body use="literal"/> <wsdl:service name="SecurityTokenService"> <wsdl:port name="UserNameWSTrustBinding_IWSTrustFeb2005Async" binding="tns:UserNameWSTrustBinding_IWSTrustFeb2005Async"> <soap12:address location="https://corp.sts.microsoft.com/adfs/services/trust/2005/usernamemixed"/> wsa10:EndpointReference wsa10:Address https://corp.sts.microsoft.com/adfs/services/trust/2005/usernamemixed <wsx:MetadataSection Dialect="http://www.w3.org/2001/XMLSchema" Identifier="http://schemas.microsoft.com/Message" xmlns=""> <xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/Message" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://schemas.microsoft.com/Message"> <xsd:complexType name="MessageBody"> xsd:sequence <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/> <wsx:MetadataSection Dialect="http://www.w3.org/2001/XMLSchema" Identifier="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns=""> <xs:schema elementFormDefault="qualified" targetNamespace="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"> <xs:element name="RequestSecurityToken" type="wst:RequestSecurityTokenType"/> <xs:complexType name="RequestSecurityTokenType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> <xs:attribute name="Context" type="xs:anyURI" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> <xs:element name="RequestSecurityTokenResponse" type="wst:RequestSecurityTokenResponseType"/> <xs:complexType name="RequestSecurityTokenResponseType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> <xs:attribute name="Context" type="xs:anyURI" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> <wsx:MetadataSection Dialect="http://www.w3.org/2001/XMLSchema" Identifier="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns=""> <xs:schema elementFormDefault="qualified" targetNamespace="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512"> <xs:element name="RequestSecurityToken" type="trust:RequestSecurityTokenType"/> <xs:complexType name="RequestSecurityTokenType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> <xs:attribute name="Context" type="xs:anyURI" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> <xs:element name="RequestSecurityTokenResponse" type="trust:RequestSecurityTokenResponseType"/> <xs:complexType name="RequestSecurityTokenResponseType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any" processContents="lax"/> <xs:attribute name="Context" type="xs:anyURI" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> <xs:element name="RequestSecurityTokenResponseCollection" type="trust:RequestSecurityTokenResponseCollectionType"/> <xs:complexType name="RequestSecurityTokenResponseCollectionType"> xs:sequence <xs:element minOccurs="1" maxOccurs="unbounded" ref="trust:RequestSecurityTokenResponse"/> <xs:anyAttribute namespace="##other" processContents="lax"/>

MEX Request and Response – GET

Modern Authentication clients like Office 2016 and Windows 10 devices doing Azure AD joining require a GET request/response supported from the MEX endpoint.

The MEX Request is as follows:

HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Microsoft-HTTPAPI/2.0 Date: Sat, 07 Dec 2013 00:25:51 GMT Connection: close

MEX Request and Response – GET

Modern Authentication clients like Office 2016 and Windows 10 devices doing Azure AD joining require a GET request/response supported from the MEX endpoint.

The MEX Request is as follows:

GET https://corp.sts.microsoft.com/adfs/services/trust/mex HTTP/1.1 Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */* Accept-Language: en-US User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729) Accept-Encoding: gzip, deflate Host: corp.sts.microsoft.com Connection: Keep-Alive

The MEX Response is as follows:

HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: text/xml; charset=UTF-8 Server: Microsoft-HTTPAPI/2.0 Date: Tue, 16 Feb 2016 19:51:19 GMT

Token Request and Response

The token request is as follows:

POST https://corp.sts.microsoft.com/adfs/services/trust/2005/usernamemixed HTTP/1.0 Connection: Keep-Alive Content-Type: application/soap+xml Accept: */* User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1; Win64; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; MSOIDCRL 7.250.4422.0; MSOIDCRL-cfg 14.0.18476.0; App IdcrlUiClient.exe, 1.0.0.0, {FBDB95BC-BFCC-4433-80CC-534B08639C11}) Content-Length: 1622 Host: corp.sts.microsoft.com

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:ps="http://schemas.microsoft.com/Passport/SoapServices/PPCRL" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wssc="http://schemas.xmlsoap.org/ws/2005/02/sc" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"> <s:Header> <wsa:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue <wsa:To s:mustUnderstand="1">https://corp.sts.microsoft.com:443/adfs/services/trust/2005/usernamemixed wsa:MessageID1386375951 wsse:Security <wsse:UsernameToken wsu:Id="user"> wsse:Username username@redmond.corp.microsoft.com wsse:Password****** <wsu:Timestamp Id="Timestamp"> wsu:Created2013-12-07T00:25:50Z wsu:Expires2013-12-07T00:30:50Z <s:Body> <wst:RequestSecurityToken Id="RST0"> wst:RequestType http://schemas.xmlsoap.org/ws/2005/02/trust/Issue wsp:AppliesTo wsa:EndpointReference wsa:Addressurn:federation:MicrosoftOnline wst:KeyType http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey

The response is as follows:

HTTP/1.1 200 OK Keep-Alive: true Content-Length: 7295 Content-Type: application/soap+xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Sat, 07 Dec 2013 00:25:51 GMT Connection: keep-alive

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> <s:Header> <a:Action s:mustUnderstand="1">http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue <a:RelatesTo>1386375951 <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <u:Timestamp u:Id="_0"> <u:Created>2013-12-07T00:25:51.758Z <u:Expires>2013-12-07T00:30:51.758Z <s:Body> <t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"> <t:Lifetime> <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2013-12-07T00:25:51.727Z <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2013-12-07T01:25:51.727Z <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"> <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing"> wsa:Addressurn:federation:MicrosoftOnline <t:RequestedSecurityToken> <saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="_341e4793-83d7-4d01-a551-ce77f8be84dc" Issuer="urn:federation:MSFT" IssueInstant="2013-12-07T00:25:51.758Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2013-12-07T00:25:51.727Z" NotOnOrAfter="2013-12-07T01:25:51.727Z"> saml:AudienceRestrictionCondition saml:Audienceurn:federation:MicrosoftOnline saml:AttributeStatement saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">9UfpavDu0hGPFgAIx0uFVw== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <saml:Attribute AttributeName="UPN" AttributeNamespace="http://schemas.xmlsoap.org/claims"> saml:AttributeValue username@redmond.corp.microsoft.com <saml:Attribute AttributeName="objectGUID" AttributeNamespace="http://tempuri.com"> saml:AttributeValue9UfpavDu0hGPFgAIx0uFVw== <saml:Attribute AttributeName="ImmutableID" AttributeNamespace="http://schemas.microsoft.com/LiveID/Federation/2008/05"> saml:AttributeValue9UfpavDu0hGPFgAIx0uFVw== <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2013-12-07T00:25:51.727Z"> saml:Subject <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">9UfpavDu0hGPFgAIx0uFVw== saml:SubjectConfirmation saml:ConfirmationMethodurn:oasis:names:tc:SAML:1.0:cm:bearer <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> ds:SignedInfo <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_341e4793-83d7-4d01-a551-ce77f8be84dc"> ds:Transforms <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> ds:DigestValueDtRsMSN4WANoCSGE8Y1BjgY/dSA= ds:SignatureValuedC44bB6RperHa332BNnHxu9q71oxzAqA/R0EO0DSIEj+PH/enAO23Sfo8tAG28iWMXhlAC57+5gV9uabSCH2C3RBuE4U6f7X4UfFgsaPDfe/jww6UGEb3hr1TT9jQPNBmZtZG5uOLtkU6qWY4vKzdekX/QNk4lSM5Io0kiKPRkDCo0ZqT4rAgxpKw1XEVLzvtIqG9jK+3YLu7L8jB9qV4WqWg8dL7eHVCKwtMt1Pw5vaCiwE7PmMGPfIHDGgcpsy/VI45ytfYdSWhpRKZrKO9emRISk3wyj3MWCf6ZTNOa6dYkuICjOjozlUKaO0K3I29qTUOyk09l+g8bKJOFvDQw== MIIFozCCBIugAwIBAgIKFaudLAABAAABYDANBgkqhkiG9w0BAQUFADCBgDETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCW1pY3Jvc29mdDEUMBIGCgmSJomT8ixkARkWBGNvcnAxFzAVBgoJkiaJk/IsZAEZFgdyZWRtb25kMR8wHQYDVQQDExZNU0lUIE1hY2hpbmUgQXV0aCBDQSAyMB4XDTEyMDgxNjA3MDgxNloXDTE0MDgxNjA3MDgxNlowITEfMB0GA1UEAxMWY29ycC5zdHMubWljcm9zb2Z0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKljSUbNGBMbrpyX9Ib0blT4JJYylkhXNsHBvx/Y0+wC4lnyzT5lsA1n19eW+Po1UOmXkoBtTEXEVVRu4E4I7flaDr3IFRMDPjtKDshECfvvwo7dU5qbepTrwKyrQp3wdbHHPtQs0TIYiwqtMHPzz2j0IoyWzmpp1IoiSgKLPFAa/0l4DJCakGYJ6U5Lofxe8TiyHcTauQORVDlszgVlLoLvxJ+NAemRMxPG5moVxBpLriVpemgrYQBsMz3mZZBV+LVXIO+M3MYVbMkVmcPBXrueo/cO+c2GSJdGYGF50e/t7Eow/O/vRMuDiaamHB80jE4KqsBEk71VmRQ29kw9mCMCAwEAAaOCAnswggJ3MD8GCSsGAQQBgjcVBwQyMDAGKCsGAQQBgjcVCIPPiU2t8gKFoZ8MgvrKfYHh+3SBT4PC7YUIjqnShWMCAWQCAQowHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMAsGA1UdDwQEAwIEsDAnBgkrBgEEAYI3FQoEGjAYMAoGCCsGAQUFBwMCMAoGCCsGAQUFBwMBMB0GA1UdDgQWBBT63jAKU6ZvyN8GEokPKu3Ef1wHzDAfBgNVHSMEGDAWgBTr2xFe+Ame2NZinP1ineOESijhJzCB7gYDVR0fBIHmMIHjMIHgoIHdoIHahk9odHRwOi8vbXNjcmwubWljcm9zb2Z0LmNvbS9wa2kvbXNjb3JwL2NybC9NU0lUJTIwTWFjaGluZSUyMEF1dGglMjBDQSUyMDIoMSkuY3Jshk1odHRwOi8vY3JsLm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9jcmwvTVNJVCUyME1hY2hpbmUlMjBBdXRoJTIwQ0ElMjAyKDEpLmNybIY4aHR0cDovL2NvcnBwa2kvY3JsL01TSVQlMjBNYWNoaW5lJTIwQXV0aCUyMENBJTIwMigxKS5jcmwwga0GCCsGAQUFBwEBBIGgMIGdMFUGCCsGAQUFBzAChklodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vcGtpL21zY29ycC9NU0lUJTIwTWFjaGluZSUyMEF1dGglMjBDQSUyMDIoMSkuY3J0MEQGCCsGAQUFBzAChjhodHRwOi8vY29ycHBraS9haWEvTVNJVCUyME1hY2hpbmUlMjBBdXRoJTIwQ0ElMjAyKDEpLmNydDANBgkqhkiG9w0BAQUFAAOCAQEARQ0xKXGApLlmHDz76uitr9TmVt2XY9Oni1w5Y7v+OwDAoyjWejGa+bbbyO5eCx/2J7ryZLr7uT7eXH0crTfevxWlVq1ixfWvYe5xrDloiLcEL9FO3cqDc2sSpzi3HyJna5XYgeH+UPH031Ce2q6pN/SfIlr+XQuWXkttEPyT9yMjyI+XR3l3Z1MoADmkm4Kdp+n8KF+KmooiFKLI6+RMQj2jQSQVAfjfhE2/2abhe5m2zP+LMoufLo6e+TulkjgRcDK6k2xuSfVdpl/Vd0jLLwJ7KE9bdkl6mRea/LZVg0CZs0SjPkC4QQ5QfQnSeitimAxj+xA7kfrwTtheMRiLEA== <t:RequestedAttachedReference> <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">\_341e4793-83d7-4d01-a551-ce77f8be84dc <t:RequestedUnattachedReference> <o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID">\_341e4793-83d7-4d01-a551-ce77f8be84dc <t:TokenType>urn:oasis:names:tc:SAML:1.0:assertion <t:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue <t:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey

References

The following link contains the summary of all the Web Service specifications and their relationship to each other, as well as pointers to the standard specs. http://msdn.microsoft.com/en-us/library/ms951274.aspx

The following link is a good starting point for understanding WSDL structure with references at the end pointing to the WSDL standard specs. http://msdn.microsoft.com/en-us/library/ms996486.aspx

Detailed messages obtaining tokens is in the WS Trust spec at http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf .

This is the version of WS Trust that is used between Azure AD and ADFS.

Introduction

Token Claim Requirements

Issuer URI

Token Contents

Client Access Policies for Location Isolation

Client End-Point Matrix

Customer Federation Setup

Establishing/Managing a Trust

Cmdlet Ordering

New Federated Domain

Converting a Domain to Federation or Standard

Management of the trust

Cmdlets Details

New-MsolDomain

Get-MsolDomainVerificationDns

Confirm-MsolDomain

Set-MsolDomainAuthentication

Get-MsolDomainFederationSettings

Set-MsolDomainFederationSettings

Sample Values for Federation Settings

Office Rich Client Protocol Flow

Office Rich Client Sample Messages

MEX Request and Response - POST

MEX Request and Response – GET

MEX Request and Response – GET

Token Request and Response

References

Related articles

10 Security Concerns for Cloud Computing

10 Ways Cloud is Changing the World

12 Advantages of Agile Software Development