You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if on login I request to set the NameIDPolicy element on the AuthnRequest, its AllowCreate attribute is hardcoded to true. Is there a particular reason for this?
If I had to think of a possible default value for this attribute in the average case, I would say that omitting the attribute (equivalent to set it to false) would be safer, while requesting it to be true could be an opt-in feature. Indeed, allowing the Identity Provider to create a new user on the fly if the principal was not previously identified might not be the most common scenario, might it?
What do you think?
As a concrete example, the Italian SPID system, for instance, requires a special out-of-band registration process for people to get proper credentials, so when a Service Provider starts a login process with SPID, the end user must already have such credentials; hence the SPID specification denies the use of AllowCreate="true".
Do you think the login process could be enhanced to support the specification of the AllowCreate flag? Please note that, if changes in #307 were accepted, from an API point of view this would just need an enrichment to the AuthRequestParams parameter class. The default value may be kept to true for backward compatibility.
The text was updated successfully, but these errors were encountered:
mauromol
changed the title
NameIDPolicy AllowCreate` hardcoded to true in AuthnRequest
NameIDPolicy AllowCreate hardcoded to true in AuthnRequest
Apr 13, 2021
Currently, if on login I request to set the
NameIDPolicy
element on theAuthnRequest
, itsAllowCreate
attribute is hardcoded totrue
. Is there a particular reason for this?If I had to think of a possible default value for this attribute in the average case, I would say that omitting the attribute (equivalent to set it to
false
) would be safer, while requesting it to betrue
could be an opt-in feature. Indeed, allowing the Identity Provider to create a new user on the fly if the principal was not previously identified might not be the most common scenario, might it?What do you think?
As a concrete example, the Italian SPID system, for instance, requires a special out-of-band registration process for people to get proper credentials, so when a Service Provider starts a login process with SPID, the end user must already have such credentials; hence the SPID specification denies the use of
AllowCreate="true"
.Do you think the login process could be enhanced to support the specification of the
AllowCreate
flag? Please note that, if changes in #307 were accepted, from an API point of view this would just need an enrichment to theAuthRequestParams
parameter class. The default value may be kept totrue
for backward compatibility.The text was updated successfully, but these errors were encountered: