Tom Poage tfpoage at
Thu Jan 12 21:54:40 GMT 2012

On 01/06/2012 05:34 PM, Cantor, Scott wrote:
> On 1/6/12 8:15 PM, "Tom Poage" <tfpoage at> wrote:
>> I ask because, as others apparently have, we've been wrestling with
>> The admin interface doesn't seem to allow one to turn
>> off RequestedAuthnContext in the AuthnRequest, so the only apparent (and
>> seemingly ugly) workaround is to add PasswordProtectedTransport to my
>> IdP's LoginHandler (handler.xml).
> You can turn it off by commenting it out of their script.

I managed to get a sneak peek at the ECMA/JavaScript code that
originates the ServiceNow SAML AuthnRequest.

> getAuthnRequestString:function ()
>   {
>     var elem = this.SAML2.createAuthnRequest ();
>     this.SAML2.createIssuer (elem);
>     this.SAML2.createNameIDPolicy (elem);
>     var rElem = this.SAML2.createRequestedAuthnContext (elem);
>     this.SAML2.createAuthnContextClassRef (rElem);
>     return this.SAML2.getEncodedSAMLRequest (elem);
>   }

Now I know what you're talking about cf. createRequestedAuthnContext()
and createAuthnContextClassRef().

Now, to push them to upgrade their buggy OpenAM/OpenSSO code.

BTW, if anyone gets stuck dealing with this mess, the SPNameQualifier
botch workaround is to set the ServiceNow entityID to be the same as the
instance (or maybe it's ACS) URL in the application's config: the
OpenAM/OpenSSO code erroneously sets SPNameQualifier in NameIDPolicy to
the URL instead of entityID, if they're the same, there's no mismatch.


More information about the users mailing list