No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

Identity Federation: Adapter as STS to non-AD directory services

This question is not answered This question is not answered

Does O365 MicrosoftOnlineServices MFG (OrgId) accept a hand crafted SAML1.0/2.0 token that look exactly like ADFS2.0 tokens?

Basically I want write an adapter (generated using WIF SDK) to our existing non-AD directory service; expose it as passive end point to browser clients for Identity federation.

Our plan is to perform below using O365 local PowerShell API…

  1. Setup Identity Federation between Adapter-STS and O365.
  2. We will sync all 20K users using PowerShell API to Cloud.

Below is what happens in a typical user scenario:

  1. A user go to on-premise portal to get authenticated through Adapter-STS; client now gets a hand crafted token (generated using WIF SDK) that looks exactly like ADFS2.0 issued token.
  2. User clicks on the O365 federated app on portal.
  3. User browser navigates to O365 link which gets redirected to passive endpoint; since user already authenticated to Adapter-STS it just redirects the user back to OrgId posting the SAML token.
  4. OrgId consumes SAML token and redirect the user back to the service.
  5. User has reached OWA/SPO.


All Replies
  • Hi Porsche,

    Before moving on, I would like to confirm if you want to user a hand crafted SAML1.0/2.0 token for Single Sign-On.

    If this is the case, based on my research, currently Office 365 doesn't support other federations except for ADFS 2.0.

    You may refer to the link below for Single sign-on: Roadmap:

    However, you can deploy two-factor authentication with ADFS for a strong authentication.

    Thanks for your understanding.

    For more information about how to use SMTP matching to match on-premises user accounts to Office 365 user accounts for Directory Synchronization, please have a look at the KB below:

    Anna Guo

  • Hi Anna,

    Thanks so much for your reply; I expected a first reply something along above lines. 

    If you analyze & understand how things work in O365-> MFG ->ADFS2.0 passive authN flow, a SAML token was posted back from on-premise ADFS2.0 instance to MFG after user authentication.  After all, the ADFS2.0 passive endpoint is an ASP.NET application.

    Also, I heard O365 will support Shibboleth going forward. Therefore I expect little more technical reason (if there is any) why I cannot write an adopter to non-AD directory services and expose is as a passive endpoint.


  • Hello Porsche,

    Support for AD FS is limited to break/fix issues related to it's implementation with Office 365 as documented. Any and all other development and/or future design and non-standard implementations are outside of our scope and we are unable to provide any future information or guidance in any way.

    Others here in the community may be working on similar issues and I hope they will "chime in" if they can add anything to the discussion.

    Mickey Levine
    Office 365 Forum Support