Requester/InvalidNameIDPolicy
vdschaaf
I am very new to SAML, and trying to set up SAML as a SP.
When connected to the openidp from Feide, everything works fine, but
when I connect to the idp we are planning to use, this error message
appears (credentials were asked for, only when valid credentials are
supplied) :
Requester/InvalidNameIDPolicy
0: /var/simplesamlphp/modules/saml2/lib/Message.php:352
(sspmod_saml2_Message::getResponseError)
1: /var/simplesamlphp/modules/saml2/lib/Message.php:690
(sspmod_saml2_Message::processResponse)
2: /var/simplesamlphp/modules/saml/www/sp/saml2-acs.php:50 (require)
3: /var/simplesamlphp/www/module.php:135 (N/A)
does anyone know where to start searching for the problem, I allready
double checked the metadata XML.
Is this something I have to fix at SP side, or does the idp have to
solve this problem ?
With kind regards,
Gerben
Tom Scavo
>
> Requester/InvalidNameIDPolicy
>
> 0: /var/simplesamlphp/modules/saml2/lib/Message.php:352
> (sspmod_saml2_Message::getResponseError)
> 1: /var/simplesamlphp/modules/saml2/lib/Message.php:690
> (sspmod_saml2_Message::processResponse)
> 2: /var/simplesamlphp/modules/saml/www/sp/saml2-acs.php:50 (require)
> 3: /var/simplesamlphp/www/module.php:135 (N/A)
Can you post the <samlp:AuthnRequest> that was sent on the wire? The
problem is most likely the AllowCreate XML attribute on the
<samlp:NameIDPolicy> element.
For background, see the "errata composite" description of AllowCreate
in SAML Core:
http://saml.xml.org/saml-specifications
Truly the AllowCreate XML attribute is the most complicated piece of
the authn request.
Tom
vdschaaf
Thanks for your answer,
> Can you post the <samlp:AuthnRequest> that was sent on the wire? The
> problem is most likely the AllowCreate XML attribute on the
> <samlp:NameIDPolicy> element.
>
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_38da1ed0e226b7c14bcd4daf2a944267e70cdb457f" Version="2.0"
IssueInstant="2010-10-10T18:04:17Z" Destination="https://
theidpdomainname/adfs/ls/" AssertionConsumerServiceURL="https://
mydomainname/saml/module.php/saml/sp/saml2-acs.php/default-sp"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
<saml:Issuer>https://mydomainname/saml/module.php/saml/sp/
metadata.php/default-sp</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-
format:transient" AllowCreate="true"/>
</samlp:AuthnRequest>
Is this what you asked for ?
- Gerben
Tom Scavo
>
> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> ID="_38da1ed0e226b7c14bcd4daf2a944267e70cdb457f" Version="2.0"
> IssueInstant="2010-10-10T18:04:17Z" Destination="https://
> theidpdomainname/adfs/ls/" AssertionConsumerServiceURL="https://
> mydomainname/saml/module.php/saml/sp/saml2-acs.php/default-sp"
> ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
> <saml:Issuer>https://mydomainname/saml/module.php/saml/sp/
> metadata.php/default-sp</saml:Issuer>
> <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-
> format:transient" AllowCreate="true"/>
> </samlp:AuthnRequest>
>
> Is this what you asked for ?
Yes. The <samlp:NameIDPolicy> is the culprit, as expected. If you
check the spec I mentioned earlier, you will find the following:
"The use of the AllowCreate attribute MUST NOT be used and SHOULD be
ignored in conjunction with requests for or assertions issued with
name identifiers with a Format of
urn:oasis:names:tc:SAML:2.0:nameid-format:transient (they preclude any
such state in and of themselves)."
I would say the IdP is free to return an error if a requester fails to
meet that requirement.
Tom
vdschaaf
Thanks, I really appreciate your help.
Do you have any idea where this setting can be changed in
simplesamlphp ?
Is it done in any config file and/or metadata file, or do I need to
make some changes to authnrequest.php
Gerben
Tom Scavo
>
> Do you have any idea where this setting can be changed in
> simplesamlphp ?
No I don't, sorry. I almost certainly know less about SSP than you do ;-)
Tom
vdschaaf
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_38da1ed0e226b7c14bcd4daf2a944267e70cdb457f" Version="2.0"
mydomainname/saml/module.php/saml/sp/saml2-acs.php/default-sp"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
<saml:Issuer>https://mydomainname/saml/module.php/saml/sp/
metadata.php/default-sp</saml:Issuer>
<samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-
</samlp:AuthnRequest>
btw: I do get authentication, the error message comes from my server
(when authenticated succesful on the idp), maybe the idp is using an
incorrect NameIDPolicy ?
Anyone ??
- Gerben
Tom Scavo
>
> btw: I do get authentication, the error message comes from my server
> (when authenticated succesful on the idp), maybe the idp is using an
> incorrect NameIDPolicy ?
Are you sure? That doesn't make any sense. What's more likely is that
the IdP is returning an error (the one you posted originally) and the
SP is just spitting it out.
Of course the <samlp:Response> element will answer that question
definitively ;-)
Tom
Olav Morken
In simpleSAMLphp, we follow the line above that one, which reads
"Requesters that do not make specific use of this attribute SHOULD
generally set it to “true” to maximize interoperability.". I interpret
the one you quoted to apply to IdPs.
> I would say the IdP is free to return an error if a requester fails to
> meet that requirement.
The error is certainly returned from the IdP. The question is why it
refuses to create a transient NameID. The best place to look for the
source of the error is the log files of the IdP. You can also try to
ask for a persistent NameID. You can do that by adding the following to
the configuration entry in authsources.php:
'NameIDPolicy' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
Regards,
Olav Morken
UNINETT / Feide