O365 integration with Forgerock, skype on android keeps using WS-Trust

Tagged: , , ,

This topic has 13 replies, 2 voices, and was last updated 6 years, 3 months ago by [email protected].

  • Author
  • #11286


    ->We’re currently having issues in connecting our Microsoft Office 365 instance to our Forgerock installation.
    Everything is working fine, except Skype for Business on android (latest version, on multiple devices).

    -I can logon fine to the web based applications
    -I can use Forgerock with the office application installed on my windows workstation (Word 2016, Excell 2016, Outlook 2016, Skype 2016, … signin works)
    -I can logon to Skype for Business on iOS
    -I can logon to the Word, Excell, Outlook app on iOS and android

    We’ve been in contact with Microsoft support, but they mentioned that Forgerock is not supported according to https://msdn.microsoft.com/en-us/library/azure/jj679342.aspx

    ->What we have configured on our OpenAM installation:

    We configured our Azure tenant explicitly with the SAML protocol, which should be fine (https://msdn.microsoft.com/en-us/library/azure/dn641269.aspx)

    Azure command: Set-MsolDomainAuthentication -DomainName …. -PreferredAuthenticationProtocol SAMLP
    We followed the guide mentioned in http://wikis.forgerock.org/confluence/pages/viewpage.action?pageId=31296618
    and created our own IDPECPsessionmapper plugin.

    This works as I’m able to logon to Outlook and I see that we receive a SAML ECP request and our OpenAM responds to it.

    ->So I’ve been doing some digging myself:

    I see the same error message as mention in OPENAM-7428: the request that we receive uses SOAP 1.2 and this is not supported for SAML.

    A further trace shows that we received the following, which looks to me like a WS-Trust 2005 request:

    <s:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope&#8221; xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion” xmlns:wsa=”http://www.w3.org/2005/08/addressing&#8221; xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy&#8221; xmlns:wssc=”http://schemas.xmlsoap.org/ws/2005/02/sc&#8221; xmlns:wsse=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&#8221; xmlns:wst=”http://schemas.xmlsoap.org/ws/2005/02/trust&#8221; xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”><s:Header><wsa:Action s:mustUnderstand=”1″>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action><wsa:To s:mustUnderstand=”1″>https://hostname/context/SSOSoap/metaAlias/idp</wsa:To><wsa:MessageID>1215501832</wsa:MessageID><ps:AuthInfo xmlns:ps=”http://schemas.microsoft.com/Passport/SoapServices/PPCRL&#8221; Id=”PPAuthInfo”><ps:HostingApp>Lync Mobile</ps:HostingApp><ps:BinaryVersion>6</ps:BinaryVersion><ps:UIVersion>1</ps:UIVersion><ps:Cookies/><ps:RequestParams>AQAAAAIAAABsYwQAAAAxMDMz</ps:RequestParams></ps:AuthInfo><wsse:Security><wsse:UsernameToken wsu:Id=”user”><wsse:Username><![CDATA[[email protected]]]></wsse:Username><wsse:Password><![CDATA[XXX]]></wsse:Password></wsse:UsernameToken><wsu:Timestamp Id=”Timestamp”><wsu:Created>2016-04-26T14:46:46Z</wsu:Created><wsu:Expires>2016-04-26T14:56:46Z</wsu:Expires></wsu:Timestamp></wsse:Security></s:Header><s:Body><wst:RequestSecurityToken Id=”RST0″><wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType><wsp:AppliesTo><wsa:EndpointReference><wsa:Address>urn:federation:MicrosoftOnline</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType></wst:RequestSecurityToken></s:Body></s:Envelope&gt;

    … so Skype on android is not sending a SAML request.

    -> As a possible solution I was thinking of the following:

    From what I understand, this WS-Trust request requires an STS, which should respond with a SAML token (I suppose Microsoft will want a SAML 1.1 token)
    Luckyly OpenAM supports WS-Trust and if I can get a valid token back on a request, and since we have an application firewall in between, I can configure it to proxy the request to the STS endpoint of OpenAM if it detects a SOAP 1.2 request(thus not a SAML ECP request, but a WS-Trust coming from Skype on android)
    OpenAM responds with a token and everything works …

    We have OpenAM 11 (with backports for the bugs mentioned in the wiki: OPENAM-3095 , OPENAM-6196), but unfortunately bug OPENAM-2196 doesn’t allow me to use STS with OpenAM 11 or 12.
    And I guess the soap STS of OpenAM 13 is out of the question as well as its documentation mentions that WS-Trust 1.4 is supported, but it looks like Skype on android is using WS-Trust 2005.

    I subsequently tried to validate if OpenAM would give a response to the WS-Trust request Microsoft is sending to us, by supplying the above WS-Trust request to the STS endpoint of a frash OpenAM 10.0.0 install, but unfortunately this gives another error:

    15-Jun-2016 10:31:12.149 SEVERE [main] org.apache.tomcat.util.digester.Digester.fatalError Parse Fatal Error at line 41 colum
    n 35: The value of attribute “password” associated with an element type “user” must not contain the ‘<‘ character.
    org.xml.sax.SAXParseException; lineNumber: 41; columnNumber: 35; The value of attribute “password” associated with an elemen
    t type “user” must not contain the ‘<‘ character.
    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:198)
    at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:177)

    ->Any ideas how to use the STS of OpenAM or how to configure O365 with Skype on Android?
    Thanks in advance!

    Best Regards,


     Peter Major

    The request you are seeing in the logs looks like a WS-Federation Active Requestor Profile request, which OpenAM will only start to “support” with OpenAM 13.5 (see OPENAM-7294).
    If you are in contact with Microsoft I would suggest to ask them why is the Android client trying to use WS-Fed when the Preferred authentication protocol is set to SAML.


    Thank you, this starts to make sense now.
    I had raised that question, but they haven’t responded to it yet.



    I tried doing a test to the nightly build of OpenAM by supplying the above mentioned skype request (with the timestamps actualized) to that OpenAM’s endpoint /openam/WSFederationServlet/sts/metaAlias/ .I’ve set the Active Request profile to enabled and created the user mentioned in the skype request.

    ->Unfortunately this leads to a nullpointer exception:

    javax.servlet.ServletException: AMSetupFilter.doFilter

    <b>root cause</b>


    ->From the source code of ActiveRequest.java

    ssoToken = authenticateEndUser(soapMessage, WSFederationMetaUtils.getAttribute(idpConfig,
    AUTHENTICATOR_CLASS, "org.forgerock.openam.saml2.plugins.DefaultWsFedAuthenticator"));
    } finally {
    try {
    SessionManager.getProvider().invalidateSession(ssoToken, request, response); <- line 179, so I reckon the ssoToken might be null

    ->I guess this means there is no ssoToken as I reckon the login failed somehow. I checked DefaultWsFedAuthenticator and it should have allowed a login to the default authentication chain (ldapService), but for some raison this fails and I don't understand yet why...

    Best Regards,


     Peter Major

    That looks like a bug (the NPE itself), but you are right, the authentication should have been successful. I would suggest to enable message level debug log and have a look at the Federation file for the ARP request.



    ->The Federation file contains the following message.

    libWSFederation:06/21/2016 01:58:29:422 PM CEST: Thread[http-nio-8080-exec-1,5,main]: TransactionId[eb1da9da-bdf2-4964-9aa8-fff040bfe899-201]
    SOAP message received: <s:Envelope …. /s:Body></s:Envelope

    ->This is the last message I see in the Federation log, and it corresponds to line 147 of ActiveRequest.java; the nullponterexception is caught by the container log (we use tomcat, so catalina.out)
    DEBUG.message(“SOAP message received: ” + new String(baos.toByteArray(), Charset.forName(“UTF-8”)));

    ->the parsing of the SOAP document looks ok in the next line 149 (parseAndValidateRequest(soapMessage, idpConfig);)
    That line only gives an error when I deliberately make an error in the request (like below), but otherwise I don’t see any error message here.

    ERROR: An unexpected error occurred while processing the SOAP message
    com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create envelope from given source:
    at com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(EnvelopeFactory.java:127)
    at com.sun.identity.wsfederation.servlet.ActiveRequest.process(ActiveRequest.java:149)

    ->this makes me believe the issue is on line 150 of ActiveRequest.java ; I’m going to try to create a custom WsFedAuthenticator plugin to see if I can learn more

    ssoToken = authenticateEndUser(soapMessage, WSFederationMetaUtils.getAttribute(idpConfig,
    AUTHENTICATOR_CLASS, “org.forgerock.openam.saml2.plugins.DefaultWsFedAuthenticator”));

    Best Regards,


     Peter Major

    If you extract the username and password from the received SOAP message and you try to authenticate in the realm’s default authentication chain, does it work?


    Yes, I can logon; accessing /openam/console brings me to /openam/XUI/#profile/details and I can see the details of that user.



    ->After I created and configured my own plugin, I started getting a response. I seems that I need to explicitly configure a class or even default class “org.forgerock.openam.saml2.plugins.DefaultWsFedAuthenticator” in the class settings under “Active Requestor Profile settings”.

    <s:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope&#8221; xmlns:a=”http://www.w3.org/2005/08/addressing&#8221; xmlns:u=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”&gt;
    <a:Action s:mustUnderstand=”1″>http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/Issue</a:Action&gt;
    <o:Security s:mustUnderstand=”1″ xmlns:o=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd”&gt;
    <u:Timestamp u:Id=”_0″>
    <wst:RequestSecurityTokenResponse xmlns:wst=”http://schemas.xmlsoap.org/ws/2005/02/trust”&gt;
    <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion” MajorVersion=”1″ MinorVersion=”1″ AssertionID=”s895fb943d649b1ff44b9a59cdafa597a5858d4a101″ Issuer=”nga-login” IssueInstant=”2016-06-21T14:15:37Z” >
    <saml:Conditions NotBefore=”2016-06-21T14:05:37Z” NotOnOrAfter=”2016-06-21T14:25:37Z” >



    Best Regards,


     Peter Major

    Does this mean that Active Requestor Profile works for you with Skype on Android?


    I’m not there yet, but definitely closer.

    I was testing in a lab environment and as a first step I wanted to check if OpenAM could respond to the request skype is sending. The next step will be to test integration with Microsoft.



    Yes, I believe I’ve cracked the problem as I managed to logon to Skype for Business on my android device :-)
    Thanks a lot for your help!

    ->I’m still using SAML except if our application firewall detects a soap 1.2 request to the SAML ECP endpoint (url /openam/SSOSoap/metaAlias/idp ) , then the request is forwarded to a separate OpenAM instance on the nightly build (url /openam/WSFederationServlet/sts/metaAlias/idp).

    ->unfortunately this conflicts with the information the the skype request between, which contains the SAML ECP url, i.e.

    </wsa:Action><wsa:To s:mustUnderstand=”1″>https://host/openam/SSOSoap/metaAlias/idp</wsa:To&gt;

    ->I noticed that the sts url is hardcoded in line 235 in ActiveRequest.java; after I changed that and recompiled, it started working though and I was able to logon.

    final String stsEndpoint = WSFederationMetaUtils.getEndpointBaseUrl(idpConfig, request)
    + “/WSFederationServlet/sts/metaAlias” + idpConfig.getMetaAlias();

    => I changed that to
    + “/SSOSoap/metaAlias” + idpConfig.getMetaAlias();

    Best Regards,


     Peter Major

    FYI I’ve raised OPENAM-9301 for the NPE. OPENAM-9293 tackles the default value problem.



    I just realized that WSFederation isn’t needed at all with the latest skype clients since they support ADAL now (what Microsoft calls “modern authentication”) although it needs to be explicitly activated on the O365 tenant and the skype windows apps. With this we can keep everything using pure SAML with our OpenAM instance.

    -the following command needs to be performed on the O365 tenant
    “Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed”

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?