The Microsoft Office 365 Application integration has been configured within Okta, utilizing WS-Federation (WS-Fed) as the designated sign-on method. Upon reviewing the Okta System Log, it was noted that Microsoft Office 365 is utilizing "SAML_1_1" as the SignOnModeType, as depicted below:
- Microsoft Office 365
- WS-Federation (WS-Fed)
- Security Assertion Markup Language (SAML)
- Here is an overview of Office 365 WS-Fed authentication steps:
- The Office365 application generates a Request Security Token (RST) and redirects the user to the SSO URL.
- Okta parses the RST request and verifies the user's identity in Active Directory or other user stores.
- Okta generates a SAML assertion inside a Request Security Token Response (RSTR) and sends it all back to the Office365 application.
- The Office 365 application receives the RSTR response and logs the user into the application.
- WS-Federation is a specification that defines mechanisms for transferring identity information using encrypted SOAP messages, adding an additional level of security.
- In the Okta System Log, see that Microsoft Office 365 in OKTA is using SAML_1_1 as SignOnModeType.
However, it is actually a SAML 1.0 assertion inside WS-TRUST Request Security Token Response (RSTR), and it is secure. - Refer to the below Microsoft documentation URLs, which explain about RequestSecurityToken Class and RequestSecurityTokenResponse Class.
- The
wst:RequestSecurityTokenResponseelement (message) contains the parameters and properties in the response sent by a security token service (STS) to a security token request (RST) made by a client. - Request Security Token Response (RSTR) contains the RequestedSecurityToken property, which represents the security token. In this case, the security token is a SAML 1.0 assertion.
- This SAML assertion contains a strong digital signature that protects the integrity of the whole SAML token, which is secure.
- Please refer to the sample screenshots below of the real SAML assertion captured using the SAML tracer.
