Skip to Content.
Sympa Menu

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

Subject: Grouper Users - Open Discussion List

List archive

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


Chronological Thread 
  • From: Tom Zeller <>
  • To: Jie Lv <>
  • Cc:
  • Subject: Re: [grouper-users] Problem with configuration of Grouper Plugin for Shibboleth
  • Date: Thu, 29 Sep 2011 09:14:59 -0500

A stack trace from that NPE would be nice.

My suggestion at this point is to replace the grouper specific
attribute resolver plugins to help locate the issue.

So, replace

<resolver:DataConnector id="MemberDataConnector2"
xsi:type="grouper:MemberDataConnector">
<grouper:Attribute id="groups" source="example"/>
</resolver:DataConnector>
<resolver:AttributeDefinition id="isMemberOf" xsi:type="grouper:Group"
sourceAttributeID="groups" >
<resolver:Dependency ref="MemberDataConnector2" />
<grouper:Attribute id="name" />
</resolver:AttributeDefinition>

with something like

<resolver:DataConnector id="TestStaticDataConnector" xsi:type="dc:Static">
<dc:Attribute id="isMemberOf">
<dc:Value>test</dc:Value>
</dc:Attribute>
</resolver:DataConnector>
<resolver:AttributeDefinition id="isMemberOf" xsi:type="ad:Simple" >
<resolver:Dependency ref="TestStaticDataConnector" />
</resolver:AttributeDefinition>

and make sure that AACLI.sh is doing what you expect.

What do you think ?

On Tue, Sep 27, 2011 at 8:21 PM, Jie Lv
<>
wrote:
>> Have you tried AACLI.sh ?
> I copied all the jar files that I'd added to idp/WEB-INF/lib to
> shibboleth-idp/lib
> The following command didn't work:
> ./aacli.sh --configDir=../conf/ --principal=10101
>
> And I got the following error information in my idp-process.log:
> 9:17:37.828 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for PrincipalConnector plugin with ID:
> saml2Transient
> 09:17:37.839 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for DataConnector plugin with ID:
> MemberDataConnector2
> 09:17:37.840 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:49] - Setting id of e
> lement 'Attribute' to 'groups'
> 09:17:37.840 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:53] - Setting source
> of element 'Attribute' to 'g:gsa'
> 09:17:37.841 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for DataConnector plugin with ID:
> MemberDataConnector
> 09:17:37.841 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:49] - Setting id of e
> lement 'Attribute' to 'admins'
> 09:17:37.842 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:53] - Setting source
> of element 'Attribute' to 'g:gsa'
> 09:17:37.850 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for DataConnector plugin with ID: static_attr
> 09:17:37.863 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for AttributeDefinition plugin with ID:
> transientId
> 09:17:37.875 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for AttributeDefinition plugin with ID:
> carsifed:username
> 09:17:37.879 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for AttributeDefinition plugin with ID:
> isMemberOf
> 09:17:37.879 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:49] - Setting id of e
> lement 'Attribute' to 'name'
> 09:17:37.880 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:53] - Setting source
> of element 'Attribute' to 'g:gsa'
> 09:17:37.880 - INFO
> [edu.internet2.middleware.shibboleth.common.config.attribute.resolver.Abstra
> ctResolutionPlugInBeanDefinitionPars
> er:55] - Parsing configuration for AttributeDefinition plugin with ID: admin
>
> 09:17:37.881 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:49] - Setting id of e
> lement 'Attribute' to 'name'
> 09:17:37.881 - DEBUG
> [edu.internet2.middleware.grouper.shibboleth.util.AttributeIdentifierBeanDef
> initionParser:53] - Setting source
> of element 'Attribute' to 'g:gsa'
> 09:17:37.958 - ERROR
> [edu.internet2.middleware.shibboleth.common.config.BaseService:188] -
> Configuration was not loaded for shibbole
> th.AttributeResolver service, error creating components.  The root cause of
> this error was: java.lang.NullPointerException: null
>
> But I did the same thing in another IdP that does NOT use Grouper Plugin,
> and the same aacli.sh command worked very well.
>
>
> -----Original Message-----
> From: Tom Zeller
> [mailto:]
> Sent: Tuesday, September 27, 2011 9:27 PM
> To: Jie Lv
> Cc:
> <>
> Subject: Re: [grouper-users] Problem with configuration of Grouper Plugin
> for Shibboleth
>
> Have you tried AACLI.sh ?
>
> On Sep 27, 2011, at 12:32 AM, "Jie Lv"
> <>
> wrote:
>
>>> If you are modding code, have you tried logging the attributes
>>> returned from the ShibbolethAttributeResolver ? I think filtering
>>> occurs afterwards, but it would be good to verify that the resolver is
>>> doing the right thing, as it appears to be.
>>
>> In my attribute-filter.xml, I had the following configuration:
>>    <afp:AttributeFilterPolicy id="releaseIsMemberOfToAnyone">
>>        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
>>        <afp:AttributeRule attributeID="isMemberOf">
>>            <afp:PermitValueRule xsi:type="basic:ANY"/>
>>        </afp:AttributeRule>
>>    <afp:AttributeFilterPolicy id="releaseAdminToAnyone">
>>        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>
>>        <afp:AttributeRule attributeID="admin">
>>            <afp:PermitValueRule xsi:type="basic:ANY"/>
>>        </afp:AttributeRule>
>>    </afp:AttributeFilterPolicy>
>>
>> In the idp-process.log, I also found the following information:
>> 10:24:10.747 - INFO [Shibboleth-Audit:970] -
>>
> 20110927T022410Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_28085b9
>> e60b049d33a
>>
> 2d8f0197ccdd84|https://sp-chat.zzu6.edu.cn/shibboleth-sp/carsifed|urn:mace:s
>> hibboleth:2.0:profiles:saml2:sso|https://idp2.pku.edu.cn
>>
> /idp/shibboleth/carsifed|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_b2a
>> ea9a1eba92338c8aad04e765a5182|10101|urn:oasis:names:tc:S
>>
> AML:2.0:ac:classes:unspecified|isMemberOf,admin,transientId,carsifed:usernam
>> e,|_27046f8ccb14094d3068e5b9f669bced||
>>
>> If I'm going to log and examine the attributes returned from the
>> ShibbolethAttributeResolver, what should I do ?
>>
>> Jie
>> -----Original Message-----
>> From:
>>
>>
>> [mailto:]
>> On Behalf Of Tom
> Zeller
>> Sent: Friday, September 23, 2011 11:39 PM
>> To: Jie Lv
>> Cc:
>>
>> Subject: Re: [grouper-users] Problem with configuration of Grouper Plugin
>> for Shibboleth
>>
>> Agree on the weirdness. I do not have a test environment right now
>> either, and it would take some cycles to establish one.
>>
>> If you are modding code, have you tried logging the attributes
>> returned from the ShibbolethAttributeResolver ? I think filtering
>> occurs afterwards, but it would be good to verify that the resolver is
>> doing the right thing, as it appears to be.
>>
>> On Fri, Sep 23, 2011 at 5:28 AM, Jie Lv
>> <>
>> wrote:
>>> Do you think you can add log statements where you see fit, rebuild, and
>> let
>>> us know how it goes?
>>> -----------------
>>>
>>> I did add the following log statement before line 261,which now became
>> line
>>> 269:
>>> 249             if (LOG.isDebugEnabled()) {
>>> 250               LOG.debug("resolve {} attributes {}", msg,
>>> attributes.size());
>>> 251               for (String key : attributes.keySet()) {
>>> 252                 for (Object value : attributes.get(key).getValues())
> {
>>> 253                   LOG.debug("resolve {} '{}' : {}", new Object[] {
>> msg,
>>> key, value });
>>> 254                 }
>>> 255               }
>>> 256             }
>>> 257             return attributes;
>>> 258           }
>>> 259         });
>>> 260         String msg = "UUUUU:";
>>> 261         if (LOG.isDebugEnabled()) {
>>> 262               LOG.debug("UUUUU resolve {} attributes {}", msg,
>>> attributes.size());
>>> 263               for (String key : attributes.keySet()) {
>>> 264                 for (Object value : attributes.get(key).getValues())
> {
>>> 265                   LOG.debug("UUUUU resolve {} '{}' : {}", new
> Object[]
>> {
>>> msg, key, value });
>>> 266                 }
>>> 267               }
>>> 268             }
>>> 269     return attributes;
>>>
>>> And this is what I got in idp-process.log:
>>> 18:20:21.985 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:250] - resolve '10101' dc 'Membe
>>> rDataConnector2' attributes 2
>>> 18:20:21.986 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:253] - resolve '10101' dc 'Membe
>>> rDataConnector2' 'id' : 10101
>>> 18:20:21.988 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:253] - resolve '10101' dc 'Membe
>>> rDataConnector2' 'groups' :
>>> Group[name=pkuid:faculty:cc,uuid=8cb08ed56aec4638beb3f4fa112d8e8a]
>>> 18:20:21.989 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:262] - UUUUU resolve UUUUU: attr
>>> ibutes 2
>>> 18:20:21.989 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:265] - UUUUU resolve UUUUU: 'id'
>>>  : 10101
>>> 18:20:21.989 - DEBUG
>>>
>>
> [edu.internet2.middleware.grouper.shibboleth.dataConnector.MemberDataConnect
>>> or:265] - UUUUU resolve UUUUU: 'gro
>>> ups' : Group[name=pkuid:faculty:cc,uuid=8cb08ed56aec4638beb3f4fa112d8e8a]
>>>
>>> 18:20:22.245 - DEBUG
>> [org.apache.xml.security.utils.DigesterOutputStream:-1]
>>> - <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML
>>> :2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema";
>>> ID="_a9e45dc1e0a92b9c0e8f065d3dab5909" IssueInstant="2011-09-23T10:20:22
>>> .187Z" Version="2.0"><saml2:Issuer
>>>
>>
> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp2.pku.e
>>> du.cn/idp/shibboleth/
>>> carsifed</saml2:Issuer><saml2:Subject><saml2:NameID
>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>>> NameQualifier="http
>>> s://idp2.pku.edu.cn/idp/shibboleth/carsifed"
>>>
>>
> SPNameQualifier="https://sp-chat.zzu6.edu.cn/shibboleth-sp/carsifed";>_5d6a4d
>>> 0514570030e
>>> 548d9a24b04cb17</saml2:NameID><saml2:SubjectConfirmation
>>>
>>
> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationDa
>>> ta Address="2001:da8:201:1130:5490:4cef:4cd8:8332"
>>> InResponseTo="_12e6eb509b60298d05b99eb5464f8ef1"
>>> NotOnOrAfter="2011-09-23T10:25:2
>>> 2.187Z"
>>>
>>
> Recipient="http://sp-chat.zzu6.edu.cn/Shibboleth.sso/SAML2/POST";></saml2:Sub
>>> jectConfirmationData></saml2:SubjectConfirmation
>>>> </saml2:Subject><saml2:Conditions NotBefore="2011-09-23T10:20:22.187Z"
>>> NotOnOrAfter="2011-09-23T10:25:22.187Z"><saml2:AudienceRestr
>>>
>>
> iction><saml2:Audience>https://sp-chat.zzu6.edu.cn/shibboleth-sp/carsifed</s
>>> aml2:Audience></saml2:AudienceRestriction></saml2:Condit
>>> ions><saml2:AuthnStatement AuthnInstant="2011-09-23T10:20:21.802Z"
>>> SessionIndex="e8b0d3333f6cdb1955dbaacade73a9f20299ef64b2e70937224
>>> e354868f74fcb"><saml2:SubjectLocality
>>>
>>
> Address="2001:da8:201:1130:5490:4cef:4cd8:8332"></saml2:SubjectLocality><sam
>>> l2:AuthnContext><s
>>>
>>
> aml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
>>> </saml2:AuthnContextClassRef></saml2:AuthnContext></saml
>>> 2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute
>>> FriendlyName="carsifed:username" Name="carsifed:username" NameFormat="ur
>>> n:oasis:names:tc:SAML:2.0:attrname-format:uri"><saml2:AttributeValue
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:type=
>>>
>>
> "xs:string">10101</saml2:AttributeValue></saml2:Attribute></saml2:AttributeS
>>> tatement></saml2:Assertion>
>>>
>>> Still, there is NO attribute named "isMemberOf" in the SAML attribute
>>> statement.
>>> Seems really weird to me.
>>>
>>> Jie
>>> -----Original Message-----
>>> From: Chris Hyzer
>>> [mailto:]
>>> Sent: Friday, September 23, 2011 1:36 PM
>>> To: Jie Lv; 'Tom Zeller'
>>> Cc:
>>>
>>> Subject: RE: [grouper-users] Problem with configuration of Grouper Plugin
>>> for Shibboleth
>>>
>>>
>>>> So I understand, what do you think the problem is between lines 199-200
> ?
>>>> ---
>>>> Line 199 is:
>>>> nameAttribute.setValues(GrouperUtil.toList(new String[] { name }));
>>>> I don't quite understand why you're using GrouperUtil.toList( ) instead
>> of
>>>> Java Util classess to construct a list?
>>>
>>> Because there is more than one way to do things, and if there is no bug
> in
>>> it, or performance problem, or maintainability problem etc, then lets
>> focus
>>> on working on more important things :)  FYI we have a lot of Grouper and
>>> Jakarta etc utility methods that are null safe / shortcuts and are used
>>> throughout the code.
>>>
>>>> The variable "attributes" in line 261, INSTEAD OF the variable in line
>> 257
>>> ,
>>>> is the value to be used by Shibboleth.
>>>> I'm not quite sure why you wrote the code like this.
>>>> But I wonder if you could insert the code for logging before line 261 to
>>>> check if the return value for function resolve() is correct?
>>>>
>>>
>>> Its an anonymous inner class that passes the value to the outer part
> which
>>> returns it... looks fine to me.  Do you think you can add log statements
>>> where you see fit, rebuild, and let us know how it goes?  :)
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>
>
>



Archive powered by MHonArc 2.6.16.

Top of Page