Grouper Users - Open Discussion List

["Jie Lv" <>]

Hi Peter,
Thanks for your quick reply.
Just now I configured my IdP to release only one attribute "isMemberOf". And
that one attribute was not released. Maybe that was the reason why there was
an attribute query and response.

Now I changed my IdP configuration to release another attribute "
carsifed:username ".

And below is what I got in the log files.
In idp-process.log on my IdP, there was:
2011-09-22 15:57:28,987 DEBUG
[edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
or:250] - resolve '10101' 
dc 'MemberDataConnector2' attributes 2
2011-09-22 15:57:28,988 DEBUG
[edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
or:253] - resolve '10101' 
dc 'MemberDataConnector2' 'id' : 10101 
2011-09-22 15:57:28,988 DEBUG
[edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
or:253] - resolve '10101' 
dc 'MemberDataConnector2' 'groups' :
Group[name=pkuid:faculty:cc,uuid=8cb08ed56aec4638beb3f4fa112d8e8a]
2011-09-22 15:57:28,988 DEBUG
[edu.internet2.middleware.grouper.shibboleth.attributeDefinition.GroupAttrib
uteDefinition:51] - resolv
e '10101' ad 'isMemberOf'
2011-09-22 15:57:28,989 DEBUG
[edu.internet2.middleware.grouper.shibboleth.attributeDefinition.GroupAttrib
uteDefinition:60] - resolv
e '10101' ad 'isMemberOf' values from dependencies
'Group[name=pkuid:faculty:cc,uuid=8cb08ed56aec4638beb3f4fa112d8e8a]'
2011-09-22 15:57:28,989 DEBUG
[edu.internet2.middleware.grouper.shibboleth.attributeDefinition.GroupAttrib
uteDefinition:92] - resolv
e '10101' ad 'isMemberOf' values 1
2011-09-22 15:57:28,989 DEBUG
[edu.internet2.middleware.grouper.shibboleth.attributeDefinition.GroupAttrib
uteDefinition:94] - resolv
e '10101' ad 'isMemberOf' value 'pkuid:faculty:cc'
2011-09-22 15:57:28,999 DEBUG
[org.apache.xml.security.algorithms.JCEMapper:-1] - Request for URI
http://www.w3.org/2001/04/xmlenc#a
es128-cbc
2011-09-22 15:57:29,060 INFO [Shibboleth-Audit:898] -
20110922T075729Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_493b006
27
8b68a310c35a6d8f95bb93f|https://sp-chat.zzu6.edu.cn/shibboleth-sp/carsifed|u
rn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp2.p
ku.edu.cn/idp/shibboleth/carsifed|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-
POST|_5e5be99e8bd569b99822e87506d849c8|10101|urn:oasis:n
ames:tc:SAML:2.0:ac:classes:unspecified|isMemberOf,transientId,carsifed:user
name,|||

On shibd.log of my SP,
2011-09-22 15:57:30 DEBUG Shibboleth.SSO.SAML2 [12]: decrypted Assertion:
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:as
sertion" ID="_aa3acb3408aed550b23be6cdc5a94b38"
IssueInstant="2011-09-22T07:57:28.990Z" Version="2.0"><saml:Issuer
Format="urn:oasis
:names:tc:SAML:2.0:nameid-format:entity">https://idp2.pku.edu.cn/idp/shibbol
eth/carsifed</saml:Issuer><saml:Subject><saml:NameID For
mat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_45fa63674df13af4d
247401747da50d6</saml:NameID><saml:SubjectConfirmation M
ethod="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml:SubjectConfirmationData
Address="2001:da8:201:1130:ed37:9447:8e69:f83" InRespons
eTo="_493b006278b68a310c35a6d8f95bb93f"
NotOnOrAfter="2011-09-22T08:02:28.990Z"
Recipient="http://sp-chat.zzu6.edu.cn/Shibboleth.sso
/SAML2/POST"/></saml:SubjectConfirmation></saml:Subject><saml:Conditions
NotBefore="2011-09-22T07:57:28.990Z" NotOnOrAfter="2011-09-
22T08:02:28.990Z"><saml:AudienceRestriction><saml:Audience>https://sp-chat.z
zu6.edu.cn/shibboleth-sp/carsifed</saml:Audience></saml:
AudienceRestriction></saml:Conditions><saml:AuthnStatement
AuthnInstant="2011-09-22T07:57:28.869Z" SessionIndex="1cb64f6be50403b864e
0b4d3dea44f87f006602160f73ebd4ffce9df456c3963"><saml:SubjectLocality
Address="2001:da8:201:1130:ed37:9447:8e69:f83"/><saml:AuthnCont
ext><saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspeci
fied</saml:AuthnContextDeclRef></saml:AuthnContext></sam
l:AuthnStatement><saml:AttributeStatement><saml:Attribute
FriendlyName="carsifed:username" Name="carsifed:username" NameFormat="urn:
oasis:names:tc:SAML:2.0:attrname-format:uri"><saml:AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.
w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">10101</saml:AttributeValue></saml:Attribute></saml:Attr
ibuteStatement></saml:As
sertion>

Still, it seems to me that Grouper Plugin could get isMemberOf attribute,
but IdP failed to release it to SP.

Do you have any experience like this?
Thanks so much!
Jie
-----Original Message-----
From: 

[mailto:]
 On Behalf Of Peter Schober
Sent: Thursday, September 22, 2011 3:47 PM
To: 

Subject: Re: [grouper-users] Problem with configuration of Grouper Plugin
for Shibboleth

* Jie Lv 
<>
 [2011-09-22 09:25]:
> In relying-party.xml, I configured the idp to release the authn statement
> and attribute statement together.

That would be the default for SAML2 (so no need to change anything in
that regard in the Shibboleth IdP), but it's not true in your case,
see below.

> In idp-process.log, I got the following message:
> 2011-09-22 14:47:17,293 INFO [Shibboleth-Audit:898] -
>
20110922T064717Z|urn:oasis:names:tc:SAML:2.0:bindings:SOAP|_8186d5f25a2e9978
> 0e
>
e7102bb08e3b4c|https://sp-chat.zzu6.edu.cn/shibboleth-sp/carsifed|urn:mace:s
> hibboleth:2.0:profiles:saml2:query:attribute|https://idp
>
2.pku.edu.cn/idp/shibboleth/carsifed|urn:oasis:names:tc:SAML:2.0:bindings:SO
> AP|_8325d826b3609fbe4d1534d020bcb008|10101||isMemberOf,transientId,|||
> 
> But on the shibd.log in the SP, I could see the text of the assertions:
[...]
> </saml:AuthnStatement></saml:Assertion>
> 
> There was NO attribute named "isMemberOf"

You're looking in the wrong place: The assertion you posted is missing
the complete <saml:AttributeStatement>, which would come
after the <saml:AuthnStatement> in the <saml:Assertion>, so the IdP is
*not* sending it with the authentication assertion. But it should be
included in the SP's log a bit further down, I would expect.

Also you can see the reference to
"urn:mace:shibboleth:2.0:profiles:saml2:query:attribute" in the IdP's
audit.log, so there was an attribute query from the SP and only there
was the attribute transferred (hence it's entry in the audit log, even
though it wasn't included in the assertion you posted).

So your Shib configuration is off in that you don't send attribute
statements over the browser, but it's working since the SP does
default does attribute queries if no attributes were recieved during
SSO.
Which now probably begs the question how you came to determine that
the attribute was not recieved in the SP. Did you check the SP's
transaction.log or the session handler (by default at
/Shibboleth.sso/Session after login).

Either way, this is not on the Grouper (or Grouper plugin) side of
things.
-peter