[Shib-Users] Attributes not being returned to SP
fol...@oakland.edu
------------------------
Miscellaneous
Client Address: 141.210.132.35
Identity Provider: https://idp.example.com:8443/idp/shibboleth
SSO Protocol: urn:oasis:names:tc:SAML:2.0:protocol
Authentication Time: 2010-03-04T15:50:21.742Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Authentication Context Decl: (none)
Session Expiration (barring inactivity): 479 minute(s)
Attributes
---------------------------------------------
Below is the error log. Any suggestions on what we can check. It also shows in the logs that it is pulling my attributes, but they are not being sent to the SP for session.
10:50:26.008 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:537] - Error resolving principal name for SAML request '_e6c1742a74b08790292dcb3fbd98534c' from relying party 'https://idp.example.com/shibboleth'
edu.internet2.middleware.shibboleth.common.attribute.AttributeRequestException: Unable to resolve principal, attribute request ID and subject name identifier may not be null
at edu.internet2.middleware.shibboleth.common.attribute.provider.ShibbolethSAML2AttributeAuthority.getPrincipal(ShibbolethSAML2AttributeAuthority.java:149) [shibboleth-common-1.1.4.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler.resolvePrincipal(AbstractSAML2ProfileHandler.java:529) [shibboleth-identityprovider-2.1.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AttributeQueryProfileHandler.processRequest(AttributeQueryProfileHandler.java:105) [shibboleth-identityprovider-2.1.5.jar:na]
at edu.internet2.middleware.shibboleth.idp.profile.saml2.AttributeQueryProfileHandler.processRequest(AttributeQueryProfileHandler.java:1) [shibboleth-identityprovider-2.1.5.jar:na]
at edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet.service(ProfileRequestDispatcherServlet.java:83) [shibboleth-common-1.1.4.jar:na]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) [servlet-api.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) [catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:77) [shibboleth-identityprovider-2.1.5.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina.jar:na]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) [catalina.jar:na]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [catalina.jar:na]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) [catalina.jar:na]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina.jar:na]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina.jar:na]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) [catalina.jar:na]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) [tomcat-coyote.jar:na]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat-coyote.jar:na]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) [tomcat-coyote.jar:na]
at java.lang.Thread.run(Thread.java:636) [na:1.6.0]
10:50:26.008 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:524] - Encoding response to SAML request _e6c1742a74b08790292dcb3fbd98534c from relying party https://sp.example.com/shibboleth
10:50:26.008 - DEBUG [org.opensaml.ws.message.encoder.BaseMessageEncoder:47] - Beginning encode message to outbound transport of type: org.opensaml.ws.transport.http.HttpServletResponseAdapter
10:50:26.009 - DEBUG [org.opensaml.saml2.binding.encoding.HTTPSOAP11Encoder:131] - Building SOAP message
10:50:26.009 - DEBUG [org.opensaml.saml2.binding.encoding.HTTPSOAP11Encoder:140] - Adding SAML message to the SOAP message's body
10:50:26.009 - DEBUG [org.opensaml.ws.message.encoder.BaseMessageEncoder:87] - Marshalling message
10:50:26.011 - DEBUG [org.opensaml.ws.message.encoder.BaseMessageEncoder:54] - Successfully encoded message.
10:50:26.012 - INFO [Shibboleth-Audit:1019] - 20100304T155026Z|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_e6c1742a74b08790292dcb3fbd98534c|https://sp.example.com/shibboleth|urn:mace:shibboleth:2.0:profiles:saml2:query:attribute|https://idp.example.com:8443/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_3350da251298a7a472a064338fcf44b2||||||
Chad La Joie
is exactly what it says and that something sent an invalid message
(namely an attribute query without a Subject/NameID).
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
Scott Cantor
> is exactly what it says and that something sent an invalid message
> (namely an attribute query without a Subject/NameID).
The SP can't do that, it won't send a query without a name to use.
One issue here is a mistake in the metadata. You do not need a SAML 2 AA
endpoint, and should not offer one in most cases. The IdP is sending the SP
no attributes to begin with, and the query step is just superfluous.
The IdP log needs to be looked at for resolution-related issues.
-- Scott
Lee Foltz
Below is the error logs, where would we verify these settings to stop this error.
We have the 'https://shibbolethtest.sys.oakland.edu/shibboleth' defined in the sp-metadata.xml and the shibboelth2.xml file. Where else would this be defined? We still get a vaild session and are also able to authenicate against our LDAP server, but no attributes are being posted on the /session page.
--------------------------------------------------
from shibd.log
2010-03-05 08:02:01 ERROR OpenSAML.SOAPClient [5]: SOAP client detected a SAML error: (urn:oasis:names:tc:SAML:2.0:status:Responder) (Error resolving principal)
2010-03-05 08:02:01 ERROR Shibboleth.AttributeResolver.Query [5]: attribute authority returned a SAML error
------------------------------------------------------------------from idp-process.log
08:02:01.417 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:525] - Resolving principal name for subject of SAML request '_59c9fb9b7f6e93905a33a0b3a9dc9246' from relying party 'https://shibbolethtest.sys.oakland.edu/shibboleth'
08:02:01.418 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:537] - Error resolving principal name for SAML request '_59c9fb9b7f6e93905a33a0b3a9dc9246' from relying party 'https://shibbolethtest.sys.oakland.edu/shibboleth'
> You'll need to inspect the rest of the log, my guess is that the error
> is exactly what it says and that something sent an invalid message
> (namely an attribute query without a Subject/NameID).
The SP can't do that, it won't send a query without a name to use.
One issue here is a mistake in the metadata. You do not need a SAML 2 AA
endpoint, and should not offer one in most cases. The IdP is sending the SP
no attributes to begin with, and the query step is just superfluous.
The IdP log needs to be looked at for resolution-related issues.
-- Scott
--
Lee Foltz
Oakland University - UTS
Systems Administrator
248-370-2675
Scott Cantor
> error.
You can get rid of the information in the IdP's metadata about supporting
SAML 2 attribute queries so the SP stops querying for no reason. Then you
need to figure out what the IdP is doing when it resolves attributes during
SSO.
I think I said this before.
> We have the 'https://shibbolethtest.sys.oakland.edu/shibboleth' defined in
> the sp-metadata.xml and the shibboelth2.xml file. Where else would this
be
> defined?
I didn't see anything implying it's not defined.
-- Scott
Lee Foltz
> Below is the error logs, where would we verify these settings to stop this
> error.
You can get rid of the information in the IdP's metadata about supporting
SAML 2 attribute queries so the SP stops querying for no reason. Then you
need to figure out what the IdP is doing when it resolves attributes during
SSO.
I think I said this before.
> We have the 'https://shibbolethtest.sys.oakland.edu/shibboleth' defined in
> the sp-metadata.xml and the shibboelth2.xml file. Where else would this
be
> defined?
Peter Schober
> We are still having no luck with the configuration to get the attributes
> posted from the IDP.
> They show up in the idp-process.log that they are being pulled from our
> LDAP, but they we still get the Error resolving principal name for SAML
> request.
As has been said several times now: the SOAP error is not the problem,
it's a side-effect of no attributes coming through. To avoid those
useless queries Scott made several suggestions only two weeks ago:
* Scott Cantor <cant...@osu.edu> [2010-02-19 16:50]:
> Concretely, make sure your IdP's metadata has no
> AttributeAuthorityDescriptor in it, or at least no SAML 2.0 binding
> support if it does have one.
[...]
> Of course, push-only SPs can also just remove the resolver plugin
> reference.
So if the SP in quesion does need to make SOAP attribute requests
(e.g. it also needs to talk to to SAML 1.x-only IdPs which haven't
changed to always push attributes) the change of choice would be to
remove "urn:oasis:names:tc:SAML:2.0:protocol" from the IdP's
<AttributeAuthorityDescriptor protocolSupportEnumeration=""> in the
metadata describing the IdP.
Note that this will not magically make attribues appear at the SP, it
will just allow the SP to skip the useless attribute query afterwards
(which will yield just the same result: no atttributes).
*Then* the IdP's logging needs to be bumped up (see the wiki for how,
ask if you don't understand it, stating specifically what part[s] are
unclear) to see what exactly the IdP does during resolving, encoding
and filtering.
> If we attached some of our configuration files would you be willing
> to look at them for us, we would greatly appreciate it.
This won't help unless you also attach all the connected databases and
LDAP systems and their config. (Note that this is a joke.)
-peter
Chad La Joie
with authentication) and I'll take a look at it.
--
Scott Cantor
>> We are still having no luck with the configuration to get the attributes
>> posted from the IDP.
>> They show up in the idp-process.log that they are being pulled from our
>> LDAP, but they we still get the Error resolving principal name for SAML
>> request.
>
> As has been said several times now: the SOAP error is not the problem,
> it's a side-effect of no attributes coming through.
Of course, that's me assuming that the includeAttributeStatement setting on
the SAML 2 SSO profile handler is still on, and it's set to push them.
I also don't really understand the principal name error on the query either,
that suggests a cluster of IdPs is involved without proper session
replication, or the resolver config as been badly mangled up, but the IdP
log during SSO should help isolate that anyway.
-- Scott
Chad La Joie
- the IdP can't load the metadata from the SP because of an untrusted
cert (line 21)
- The attribute resolver pulls the attributes uid, sn, cn, and
edupersonprimaryaffiliation from the ldap (lines 358 - 361)
- The attribute eduPersonPrimaryAffiliation had no values (line 364)
- Attributes the left the resolver and went in to the filter engine were
uid, surname, commonName, transientId (line 441)
- Values for the attributes uid, commonName, surname were removed by
your attribute filter (line 452 - 454)
- Only the transient ID attribute was left for release to the service
provider (line 455)
So, no attributes are going to be release because that's what your
filter file told the IdP to do. In addition, that attribute
eduPersonPrimaryAffiliation has no values because, as the documentation
says, attribute IDs are case sensitive and eduPersonPrimaryAffiliation
!= edupersonprimaryaffiliation
So, no real mystery here if you read through the log file.
On 3/8/10 7:34 AM, Lee Foltz wrote:
> I attached the idp-process.log.
>
> Thanks again,
>
>
>
> On Sat, Mar 6, 2010 at 9:19 AM, Chad La Joie <laj...@itumi.biz
> <mailto:laj...@itumi.biz>> wrote:
>
> Send the idp-process.log, on debug, for *one* *full* request (starting
> with authentication) and I'll take a look at it.
>
> On 3/6/10 8:48 AM, Lee Foltz wrote:
> > We are still having no luck with the configuration to get the
> attributes
> > posted from the IDP.
> > They show up in the idp-process.log that they are being pulled
> from our
> > LDAP, but they we still get the Error resolving principal name for
> SAML
> > request.
> >
> > If we attached some of our configuration files would you be willing to
> > look at them for us, we would greatly appreciate it.
> >
> >
> >
> > On Fri, Mar 5, 2010 at 9:58 AM, Scott Cantor <cant...@osu.edu
> <mailto:cant...@osu.edu>
> > <mailto:cant...@osu.edu <mailto:cant...@osu.edu>>> wrote:
> >
> > > Below is the error logs, where would we verify these settings to
> > stop this
> > > error.
> >
> > You can get rid of the information in the IdP's metadata about
> > supporting
> > SAML 2 attribute queries so the SP stops querying for no reason.
> > Then you
> > need to figure out what the IdP is doing when it resolves
> attributes
> > during
> > SSO.
> >
> > I think I said this before.
> >
> > > We have the 'https://shibbolethtest.sys.oakland.edu/shibboleth'
> > defined in
> > > the sp-metadata.xml and the shibboelth2.xml file. Where else
> > would this
> > be
> > > defined?
> >
> > I didn't see anything implying it's not defined.
> >
> > -- Scott
> >
> >
> >
>
> --
> Chad La Joie
> www.itumi.biz <http://www.itumi.biz/>
Yang, Jack
Thanks a lot.
Jack Yang
-----------------------------------------
The information contained in this email message and its attachments
is intended only for the private and confidential use of the
recipient(s) named above, unless the sender expressly agrees
otherwise.
Transmission of email over the Internet is not a secure
communications medium. If you are requesting or have requested the
transmittal of personal data, as defined in applicable privacy laws
by means of email or in an attachment to email, you must select a
more secure alternate means of transmittal that supports your
obligations to protect such personal data.
If the reader of this message is not the intended recipient and/or
you have received this email in error, you must take no action
based on the information in this email and you are hereby notified
that any dissemination, misuse or copying or disclosure of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by email and
delete the original message.
Scott Cantor
> idP and SP? I have access to Shibboleth 2.0x documents online, but these
> online documents are not enough to get this to work.
The wiki is the only documentation. If you're unclear on something, we can't
improve it unless we know what specifically is most unclear.
-- Scott
Lee Foltz
10:42:48.237 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:70] - shibboleth.AttributeFilterEngine filtering 5 attributes for principal foltz2
10:42:48.238 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy releaseTransientIdToAnyone is active for principal foltz2
10:42:48.238 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131] - Filter policy releaseTransientIdToAnyone is active for principal foltz2
10:42:48.238 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute transientId for principal foltz2
10:42:48.238 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonAffiliation for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonPrimaryAffiliation for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute uid for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute cn for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:122] - Evaluating if filter policy null is active for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:131] - Filter policy null is active for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonPrimaryAffiliation for principal foltz2
10:42:48.239 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonAffiliation for principal foltz2
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute eduPersonEntitlement for principal foltz2
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute uid for principal foltz2
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:156] - Processing permit value rule for attribute cn for principal foltz2
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:101] - Removing attribute from return set, no more values: surname
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:101] - Removing attribute from return set, no more values: commonName
10:42:48.240 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.filtering.provider.ShibbolethAttributeFilteringEngine:106] - Filtered attributes for principal foltz2. The following attributes remain: [uid, eduPersonPrimaryAffiliation, transientId]
Andy Swiffin
<5965D73BEA5F3042A55A3...@NUMEVP21.na.imtn.com>, "Yang, Jack"
<Jack...@ironmountain.com> wrote:
> Can someone help me to find more in-depth configuration documents for both idP
> and SP? I have access to Shibboleth 2.0x documents online, but these online
> documents are not enough to get this to work.
> Thanks a lot.
> Jack Yang
There is quite a bit of documentation on the UK Federation site at:
http://www.ukfederation.org.uk/content/Documents/Search?q=Documents/
particularly:
http://www.ukfederation.org.uk/content/Documents/Setup2IdP
and
http://www.ukfederation.org.uk/content/Documents/Setup2IdPApacheHttpd
and some good documentation by Frances Lowry at:
http://shibsp.ntu.ac.uk/confluence/display/SHIB2/Windows+IdP+installation
and by the people at SWITCH (swiss federation) at:
http://www.switch.ch/aai/support/documents/
and by the Irish federation:
http://www.edugate.ie/drupal/?q=InstallGuide
Of course these are all specific to the particular federations they are aimed at, but you should be able to spot the common points.
Andy Swiffin
Dundee
Scotland
************************************************************
Please consider the environment. Do you really need to print this email?
Peter Schober
> There is quite a bit of documentation on the UK Federation site at:
> and some good documentation by Frances Lowry at:
> and by the people at SWITCH (swiss federation) at:
> and by the Irish federation:
While reading those might help understanding (or it might not), it's
not recommended (by the Shibbboleth project) the use of any of those,
unless you're actually planning to join one of those federations, of
course. Obviously the project cannot support, correct, improve or
explain any part of these sites. And the organisations responsible for
the content there will only support their own constituency.
So when using those sets of docs you're practically on your own.
Not a good position to be in when you're only begining and having
trouble making sense of the documentation.
Either way, I'd recommend to stick to /one/ set of documentation only,
not taking bits (e.g., mindlessly copying and pasting config snippets)
from several different sites. This will neither help with
understanding, nor will it get you a working configuration.
-peter
Chad La Joie
say is true. Those docs are good if your specific need is joining one
of those federation. If your need is to find a way to configure the
software in some particular, special-to-your-needs, way than those docs
aren't helpful.
On 3/9/10 5:48 AM, Peter Schober wrote:
> While reading those might help understanding (or it might not), it's
> not recommended (by the Shibbboleth project) the use of any of those,
> unless you're actually planning to join one of those federations, of
> course. Obviously the project cannot support, correct, improve or
> explain any part of these sites. And the organisations responsible for
> the content there will only support their own constituency.
Andy Swiffin
I'd have to totally disagree.
The documents from third parties are indeed very useful in all kinds of ways, I have used helpful documentation from Ireland, Germany, Switzerland, Australia, Belgium, Canada, the UK and even, heaven forbid, the US to help me gain a wider understanding of how to do what I need to. The docs produced by other parties always cover much more than just their local configuration, what's federation specific about the install process, ldap configuration, using scripts for attribute release etc?
I would encourage anyone to cast their reading net as wide as possible to gain as broad a view as possible. I cannot understand this narrow attitude.
Andy Swiffin
Dundee
p.s. I'm sure I will have missed some countries in my list above, whoever you are, thankyou for your contributions to the knowledge base.
Lee Foltz
Miscellaneous Client Address: 141.210.132.35 Identity Provider: https://shibbolethtest.sys.oakland.edu:8443/idp/shibboleth SSO Protocol: urn:oasis:names:tc:SAML:1.1:protocol Authentication Time: 2010-03-09T16:03:08.118Z
Authentication Context Class: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport Authentication Context Decl: (none)
Session Expiration (barring inactivity): 468 minute(s) Attributes cn: 1 value(s) eduPersonPrimaryAffiliation: 1 value(s)
Peter Schober
> Our Shibboleth.sso/Session is now showing it has 2 attributes posted, but
> why can't we see the actual values of them?
Because the default value is to not show them.
https://spaces.internet2.edu/display/SHIB2/NativeSPHandler#NativeSPHandler-SessionHandler
"showAttributeValues (boolean) (defaults to false)"
-peter