[Shib-Users] Getting Simple SP to Authenticate w/ IdP
Ian MacDonald
I am running a small POC (IdP authenticating via LDAP, SP protecting and
extending SSO to some web services, sp.example.org/secure to start)
When I access my page I am redirected to
http://sp.example.org/Shibboleth.sso/SAML2/POST where I get this simple
error related to the profile being used
-Web Page Output-
opensaml::FatalProfileException at
(http://sp.example.org/Shibboleth.sso/SAML2/POST)
SAML response contained an error.
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
My understanding is that I should be presented with some sort of SSO
login page where I can authenticate.
Here are some relevant lines from my IdP Process.log
I am concerned about two things; the "entity descriptor not matching
EntityID" message and the "no user identifed by login handler."
Any help appreciated,
Ian
15:03:52.042 - INFO [Shibboleth-Access:73] - 20100331T190352Z|X.X.X.X|idp.example.org:443|/profile/SAML2/Redirect/SSO|
15:03:52.054 - DEBUG [org.opensaml.saml2.binding.decoding.HTTPRedirectDeflateDecoder:104] - Decoded SAML message
15:03:52.054 - DEBUG [org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder:111] - Extracting ID, issuer and issue instant from request
15:03:52.055 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:193] - Checking child metadata provider for entity descriptor with entity ID: https://sp.example.org/shibboleth
15:03:52.055 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:237] - Searching for entity descriptor with an entity ID of https://sp.example.org/shibboleth
15:03:52.057 - DEBUG [org.opensaml.util.storage.ReplayCache:131] - Writing message ID https://sp.example.org/shibboleth_7aba222db248e935d4977c97575389e8 to replay cache with expiration time 2010-03-31T15:08:52.057-04:00
15:03:52.058 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:193] - Checking child metadata provider for entity descriptor with entity ID: https://sp.example.org/shibboleth
15:03:52.058 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:237] - Searching for entity descriptor with an entity ID of https://sp.example.org/shibboleth
15:03:52.058 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:95] - Metadata document does not contain an EntityDescriptor with the ID https://sp.example.org/shibboleth
15:03:52.058 - DEBUG [org.opensaml.saml2.binding.security.SAML2AuthnRequestsSignedRule:91] - SPSSODescriptor for entity ID 'https://sp.example.org/shibboleth' does not require AuthnRequests to be signed
15:03:52.059 - INFO [org.opensaml.common.binding.security.SAMLProtocolMessageXMLSignatureSecurityPolicyRule:99] - SAML protocol message was not signed, skipping XML signature processing
15:03:52.060 - DEBUG [org.opensaml.ws.message.decoder.BaseMessageDecoder:81] - Successfully decoded message.
15:03:52.061 - DEBUG [org.opensaml.common.binding.decoding.BaseSAMLMessageDecoder:208] - SAML message intended destination endpoint matched recipient endpoint
15:03:52.061 - DEBUG [org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:193] - Checking child metadata provider for entity descriptor with entity ID: https://sp.example.org/shibboleth
15:03:52.061 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:237] - Searching for entity descriptor with an entity ID of https://sp.example.org/shibboleth
15:03:52.061 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:95] - Metadata document does not contain an EntityDescriptor with the ID https://sp.example.org/shibboleth
15:03:52.085 - ERROR [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:564] - No user identified by login handler.
15:03:52.086 - ERROR [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:515] - Authentication failed with the error:
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException: No user identified by login handler.
at edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine.validateSuccessfulAuthentication(AuthenticationEngine.java:565) [shibboleth-identityprovider-2.1.5.jar:na]
Below is my basic setup information:
My simple web page is protected as such at http(s)://sp.example.org/secure
<Location /secure>
AuthType shibboleth
ShibRequestSetting requireSession 1
ShibRequestSetting applicationId default
require valid-user
</Location>
My shibboleth2.xml on the SP has the following relevant bits
<ApplicationDefaults id="default" policyId="default"
entityID="https://sp.example.org/Shibboleth.sso/Metadata"
homeURL="https://sp.example.org/secure/"
REMOTE_USER="eppn persistent-id targeted-id"
signing="false" encryption="false">
<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="Intranet"
relayState="cookie" entityID="https://idp.example.org/idp/shibboleth">
SP Metadata:https://sp.example.org/Shibboleth.sso/Metadata
IDP Metadata:https://idp.example.org/idp/shibboleth
Each provider has a FileBackedHTTPProvider configured to consume, update
and locally store the metadata.xml
The IdP is configured, and exposing its metadata and consuming the SP
metadata without apparent issue.
-idp-process.log-
14:17:52.860 - DEBUG [org.opensaml.saml2.metadata.provider.ResourceBackedMetadataProvider:186] - Refreshing metadata from resource /usr/local/shibboleth-idp/metadata/idp-metadata.xml
14:17:53.255 - DEBUG [org.opensaml.saml2.metadata.provider.ResourceBackedMetadataProvider:160] - Next refresh of metadata from resource /usr/local/shibboleth-idp/metadata/idp-metadata.xml scheduled in 28800000ms
14:17:53.408 - DEBUG [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:228] - Refreshing cache of metadata from URL http://sp.example.org/Shibboleth.sso/Metadata, max cache duration set to 2880 seconds
14:17:53.409 - DEBUG [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:271] - Fetching metadata document from remote server
14:17:53.938 - DEBUG [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:284] - Unmarshalled metadata from remote server
14:17:53.938 - DEBUG [org.opensaml.saml2.metadata.provider.FileBackedHTTPMetadataProvider:106] - Writting retrieved metadata to backup file /usr/local/shibboleth-idp/metadata/exsp-metadata.xml
The SP is configured exposing its metadata, and consuming the IdP
metadata without apparent issue.
-shibd.log-
2010-03-31 14:40:03 INFO Shibboleth.Application : building MetadataProvider of type Chaining...
2010-03-31 14:40:03 INFO OpenSAML.Metadata.Chaining : building MetadataProvider of type XML
2010-03-31 14:40:03 DEBUG OpenSAML.MetadataProvider.XML : using remote resource (https://idp.example.org/idp/shibboleth)
2010-03-31 14:40:03 DEBUG OpenSAML.MetadataProvider.XML : backup remote resource with (/etc/shibboleth/exidp-metadata.xml)
I have my released attributes defined in the attribute-map.xml
<Attribute name="urn:mace:dir:attribute-def:mail" id="mail"/>
<Attribute name="urn:mace:dir:attribute-def:title" id="title"/>
<Attribute name="urn:mace:dir:attribute-def:mail" id="mail"/>
<Attribute name="urn:mace:dir:attribute-def:title" id="title"/>
These match what my IdP can see released from my LDAP
ilum:/usr/local/shibboleth-idp/bin# ./aacli.sh --configDir=../conf --principal=imacdonald
<?xml version="1.0" encoding="UTF-8"?><saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">imacdonald</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="title" Name="urn:oid:2.5.4.12" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Director, Product Management</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
Chad La Joie
configured on the IdP.
[1] https://spaces.internet2.edu/display/SHIB2/IdPMetadataProvider
[2] https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Scott Cantor
> EntityID" message and the "no user identifed by login handler."
Your SP config claims to be identifying itself as an entityID ending in /Shibboleth.sso/Metadata but the request to the IdP is using an identifier of the more typical example form. You would have to be manually manipulating the request or mistaken about the config for that to be the case, but everything has to match in any case.
The proximate error, which the metadata part is irrelevant to, is that you have authentication missing from the IdP setup and it's not identifying a user during the process. You have a login handler issue of some kind.
-- Scott
Ian MacDonald
> > I am concerned about two things; the "entity descriptor not matching
> > EntityID" message and the "no user identifed by login handler."
>
> Your SP config claims to be identifying itself as an entityID ending
> in /Shibboleth.sso/Metadata but the request to the IdP is using an
> identifier of the more typical example form. You would have to be
> manually manipulating the request or mistaken about the config for
> that to be the case, but everything has to match in any case.
I had just modified my shibboleth2.xml
entityID="https://sp.example.org/Shibboleth.sso/Metadata"
from
entityID="https://sp.example.org/shibboleth"
Noting it was the former in my relying-party.xml; I thought this might
be the reason for the mismatch error.. turns out not to be the case.
I am also obfuscating the domain and IP namespace.. so the logs are from
just prior to this change.
I found the URL for metadata hard to *find* noting the default is not
the *typical example* and I am wondering why this might be the case.. I
assume that new SP 2.3.1 just uses a slightly different default than
most the example docs.
Off to revisit the iDP metadata and login handler setup.
thanks
Scott Cantor
> be the reason for the mismatch error.. turns out not to be the case.
You don't need any reference to the SP's *name* in relying-party.xml in most cases.
> I found the URL for metadata hard to *find* noting the default is not
> the *typical example* and I am wondering why this might be the case.
I don't know precisely what you mean by "the URL for metadata".
In general you get metadata by constructing a valid document based on your chosen settings and locations. Any other tools are simply a shortcut to assist with constructing that.
> I assume that new SP 2.3.1 just uses a slightly different default than
> most the example docs.
I don't know what docs you're thinking of, so I couldn't say.
-- Scott
Ian MacDonald
> > Noting it was the former in my relying-party.xml; I thought this might
> > be the reason for the mismatch error.. turns out not to be the case.
>
> You don't need any reference to the SP's *name* in relying-party.xml in most cases.
I thought that by defining my SP as a metadata source in my iDp I
increased the level of trust, and ultimately give me more flexibility in
what I can do there, in terms of restricting profiles, etc.
I figured default is better than anonymous in my case.
> > I found the URL for metadata hard to *find* noting the default is not
> > the *typical example* and I am wondering why this might be the case.
> I don't know precisely what you mean by "the URL for metadata".
I mean the place where the SP publishes the configuration; in my case
its here. This is the metatdate URL I use to have my iDP pull the
latest config.
https://sp.example.org/Shibboleth.sso/Metadata
> In general you get metadata by constructing a valid document based on
> your chosen settings and locations. Any other tools are simply a
> shortcut to assist with constructing that.
Right, sort of like the difference between using OIF 11g GUI, and
manipulating the namespace directly. All for the purpose of creating a
single configuration document to share with another provider.
> > I assume that new SP 2.3.1 just uses a slightly different default than
> > most the example docs.
>
> I don't know what docs you're thinking of, so I couldn't say.
Default EntityID in shibboleth2.xml was /shibboleth
So, I though maybe the message below from my iDp
Metadata document does not contain an EntityDescriptor with the ID
https://sp.n8id.org/shibboleth
meant the EntityID was not found withing my iDp metadata, as I had
defined it in relying-party.xml, so I changed it to match; I expect this
had no impact, other than to change this "identifier"
Ian
Scott Cantor
> increased the level of trust, and ultimately give me more flexibility in
> what I can do there, in terms of restricting profiles, etc.
The SP's metadata source is not it's name. It may in some rare, mostly pedantic/testing-related use cases be found by resolving it's name, but not normally, and even in such cases the metadata configuration you have to create does not imply that you need a RelyingParty definition based on the SP's name unless you actually need to use different profile settings for it.
> I figured default is better than anonymous in my case.
Neither requires per-SP setup, that's all I'm saying. Metadata is a separate issue because what makes sense for testing bears no relationship to real world usage. Most real world setups are getting metadata in batches, not one by one.
> I mean the place where the SP publishes the configuration; in my case
> its here. This is the metatdate URL I use to have my iDP pull the
> latest config.
> https://sp.example.org/Shibboleth.sso/Metadata
That's just where the SP provides a sample of metadata for assistance in constructing the real metadata you give to IdPs via a mechanism that injects more completeness, and trust. Contacting that endpoint directly from the IdP is not useful for security purposes, and will produce incomplete metadata in most cases and inaccurate metadata in some.
> Right, sort of like the difference between using OIF 11g GUI, and
> manipulating the namespace directly. All for the purpose of creating a
> single configuration document to share with another provider.
I would hope/suspect that Oracle's GUI is more capable of producing something accurate than that handler is.
But the point is that generating and eyeballing such a document and giving it to a partner is not the same as telling the partner to just pull it from some limited example code.
> Default EntityID in shibboleth2.xml was /shibboleth
That's the intended default naming convention and has nothing to do with where you get or supply metadata from in the majority of scenarios.
-- Scott
Ian MacDonald
My goal for today is just UserPassword authentication.
So, if I remove SP metadata sources in IdP relying-party information, I
just need to ensure anonymous entities use an SSO profile and
UserPassword auth by default. I have added the defaultAuthMethod to the
anonymous to support this.
<AnonymousRelyingParty provider="https://idp.example.org/idp/shibboleth"
defaultAuthenticationMethod="UsernamePassword"
defaultSigningCredentialRef="IdPCredential" />
Additionally, I had not noticed some commenting in handler.xml I missed
removing around the UserPassword config I need. So I uncommented that
too.
<LoginHandler xsi:type="UsernamePassword"
jaasConfigurationLocation="file:///usr/local/shibboleth-idp/conf/login.config">
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
</LoginHandler>
My login.config appears to still be correct.
So, now I have removed all metadata sources from my iDp.
I changed my SP Entity ID back to
entityID="https://sp.example.org/shibboleth" as it seems to make more
sense to me this way.
Now, when I hit the /secure page, I get
Error Message: SAML 2 SSO profile is not configured for relying party
'https://sp.n8id.org/shibboleth'
Soo.. it looks like I need to do something to the anonymous setup. I am
investigating the profile options for anonymous further.
On Wed, 2010-03-31 at 17:41 -0400, Scott Cantor wrote:
> > I thought that by defining my SP as a metadata source in my iDp I
> > increased the level of trust, and ultimately give me more flexibility in
> > what I can do there, in terms of restricting profiles, etc.
>
> The SP's metadata source is not it's name.
EntityID != Source URL (does not need to for any signature validation)
> It may in some rare, mostly pedantic/testing-related use cases be
> found by resolving it's name, but not normally, and even in such cases
> the metadata configuration you have to create does not imply that you
> need a RelyingParty definition based on the SP's name unless you
> actually need to use different profile settings for it.
I get the SSO profile not avail without either establishing a relying
party config, or tweaking the defaults for anonymous
> > I figured default is better than anonymous in my case.
>
> Neither requires per-SP setup, that's all I'm saying. Metadata is a
> separate issue because what makes sense for testing bears no
> relationship to real world usage. Most real world setups are getting
> metadata in batches, not one by one.
Batches from possibly a trusted third party for instance.
> > I mean the place where the SP publishes the configuration; in my case
> > its here. This is the metatdate URL I use to have my iDP pull the
> > latest config.
> > https://sp.example.org/Shibboleth.sso/Metadata
>
> That's just where the SP provides a sample of metadata for assistance
> in constructing the real metadata you give to IdPs via a mechanism
> that injects more completeness, and trust. Contacting that endpoint
> directly from the IdP is not useful for security purposes, and will
> produce incomplete metadata in most cases and inaccurate metadata in
> some.
So if I use the SP source URL for my test case IdP relying party
metatdata source (understanding the security requirement of providing
metadata differently for a production scenario) are you saying that my
IdP will have incomplete metadata? Or are you saying that there are
always tweaks required after the fact to make it *complete* in every
aspect (i.e. contact details missing, unnecessary profile support) but
it will be functional in how it implements the federation model. (I
assume the later)
> But the point is that generating and eyeballing such a document and
> giving it to a partner is not the same as telling the partner to just
> pull it from some limited example code.
Right, this I understand. Keep in mind this is a POC for me, not a
basis for any production related methodology.
>
Scott Cantor
> just need to ensure anonymous entities use an SSO profile and
> UserPassword auth by default. I have added the defaultAuthMethod to the
> anonymous to support this.
I believe that field is not for identifying the login handler type, but for the SAML authn context URI value that in turn maps to the suporting handler.
> Soo.. it looks like I need to do something to the anonymous setup. I am
> investigating the profile options for anonymous further.
You have to copy in the profile handler(s) you want anonymous support for, but that's not a typical concern, and testing generally assumes metadata is provided.
> I get the SSO profile not avail without either establishing a relying
> party config, or tweaking the defaults for anonymous
Then the metadata was/is wrong in some way (as was indicated originally by the error about the entityID not found in the metadata). It was falling through to anonymous behavior.
> So if I use the SP source URL for my test case IdP relying party
> metatdata source (understanding the security requirement of providing
> metadata differently for a production scenario) are you saying that my
> IdP will have incomplete metadata?
It will have only things it can derive from the configuration. Enough for testing, if it's accurate and vetted against the expectations of the deployer. Used silently without any sanity checking, any number of problems can occur based on other unpredictable factors like web server settings.
It won't automatically produce correct metadata for virtually hosted systems, for example.
> Or are you saying that there are
> always tweaks required after the fact to make it *complete* in every
> aspect (i.e. contact details missing, unnecessary profile support) but
> it will be functional in how it implements the federation model. (I
> assume the later)
Mostly yes, but "functional" doesn't mean "doing what is necessary to accomplish specific behavior".
> Right, this I understand. Keep in mind this is a POC for me, not a
> basis for any production related methodology.
I understand, but it only works "when it works". When it doesn't, it tends to hide problems.
-- Scott