node-saml / passport-saml

SAML 2.0 authentication with Passport

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Extend available options for NameIdPolicy attributes

harrdou opened this issue · comments

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
options.identifierFormat currently allows configuration of the Format attribute of <NameIDPolicy> in authentication requests.

We have a use cases that also requires the ability to specify the value of the AllowCreate attribute, currently hard-coded here ...

"@AllowCreate": "true",
...as well as the SPNameQualifier attribute (we use the Affiliations feature of SAML).

Describe alternatives you've considered
It's a fairly straightforward feature to add, once the new option names are agreed upon. Perhaps options.allowCreate and options.spNameQualifier?

I'd be happy to submit a PR for this if everyone thinks it is worth including and the above option names are acceptable.

We are open to any enhancement that corresponds to the SAML spec. Do you have a reference to the spec so that we can make sure the enhancement is coded correctly? Also, you'll probably want to make the PR over with the node-saml project here.

Ok thanks. These attributes and their use are described in section 3.4.1.1 of SAML Core.

I'll start working on this and hopefully have the PR ready in the next couple of weeks.

Speaking of the spec, the current implementation does not follow the spec's recommendation for AllowCreate...

Requesters that do not make specific use of this attribute SHOULD generally set it to “true” to
maximize interoperability.

... as the element (with AllowCreate="true") is currently only included when options.identifierFormat is specified and, as per the spec, AllowCreate...

Defaults to "false" if not present or the entire element is omitted.

I'll go ahead and implement what the spec recommends for now, but we should discuss as this will be a change to current behaviour that could impact deployments.

Thank you for pointing that out. Feel free to include links to the documentation.

As for breaking changes, now is the time because our next release will be 4.0 and it is expected to have several breaking changes.