cannot pull isMemberOf attribute

[Jeffrey Crawford]

Using A script like that could be pretty inefficient if the group list
is pretty big and you have lots of authentications going on we opted
for creating the structure in the Resolver and then using filters to
determine if entitlement is granted based on group membership.

In the resolver config make a couple new data sources. One's an LDAP
connector that looks for group membership based on the requestContext
and the other is a static value you want returned when group lookup is
successful:
    <resolver:DataConnector id="GroupLDAP" xsi:type="dc:LDAPDirectory"
        ldapURL="ldap://ldap.example.edu"
        useStartTLS="true"
        baseDN="ou=groups,dc=ucsc,dc=edu"
        principal="cn=serviceAcct,dc=ucsc,dc=edu"
        principalCredential="secret">
        <dc:FilterTemplate>
            <![CDATA[
                (memberUid=$requestContext.principalName)
            ]]>
        </dc:FilterTemplate>
    </resolver:DataConnector>

    <resolver:DataConnector id="staticAttributes" xsi:type="dc:Static">
        <dc:Attribute id="eduPersonEntitlementGroupStatic">
            <dc:Value>urn:mace:dir:entitlement:common-lib-terms</dc:Value>
        </dc:Attribute>
    </resolver:DataConnector>

Next Create two Attribute definitions that reference the above data sources:
    <resolver:AttributeDefinition xsi:type="ad:Simple"
id="eduPersonEntitlementDynamic"

sourceAttributeID="eduPersonEntitlementGroupStatic">
        <resolver:Dependency ref="staticAttributes" />

        <resolver:AttributeEncoder xsi:type="enc:SAML1String"
name="urn:mace:dir:attribute-def:eduPersonEntitlement" />
        <resolver:AttributeEncoder xsi:type="enc:SAML2String"
name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"
                                   friendlyName="eduPersonEntitlement" />
    </resolver:AttributeDefinition>
    <resolver:AttributeDefinition xsi:type="ad:Simple" id="groupCn"
sourceAttributeID="cn">
        <resolver:Dependency ref="GroupLDAP" />

           <resolver:AttributeEncoder xsi:type="enc:SAML1ScopedString"
name="urn:oid:2.5.4.3" />
           <resolver:AttributeEncoder xsi:type="enc:SAML2ScopedString"
name="urn:oid:2.5.4.3"

friendlyName="cn" />
    </resolver:AttributeDefinition>

Then The filter can just have the definitions based on the service level:
    <afp:AttributeFilterPolicy id="dynamicGroup">
        <afp:PolicyRequirementRule xsi:type="basic:AND">
           <afp:PolicyRequirementRule
xsi:type="basic:AttributeRequesterString"
value="http://someurl/shibboleth-sp" />

           <basic:Rule xsi:type="basic:OR">
             <basic:Rule xsi:type="basic:AttributeValueString"
attributeID="groupCn" value="group1" />
             <basic:Rule xsi:type="basic:AttributeValueString"
attributeID="groupCn" value="group2" />
           </basic:Rule>

        <afp:AttributeRule attributeID="eduPersonEntitlementDynamic">
            <afp:PermitValueRule xsi:type="basic:ANY" />
        </afp:AttributeRule>
    </afp:AttributeFilterPolicy>
Jeffrey E. Crawford
ITS Application Administrator (IdM)
831-459-4365
jeffreyc at ucsc.edu

Both pilots and IT professionals require training and currency before
charging into clouds!
---------------------------------------


On Fri, Mar 7, 2014 at 8:23 AM, Christopher Bongaarts <cab at umn.edu> wrote:
> On 3/7/2014 4:13 AM, Cameron Kerr wrote:
>> Suggest you only request the attributes you need; you'll get better LDAP performance that way.
>
> Better IdP performance, probably, as it might not need to parse as much
> response data.
>
> LDAP server performance may vary.  Some servers have an "entry cache"
> with the data preformatted and ready to go if the entry has been
> requested recently. If Shib's view is identical to any other significant
> LDAP consumer, requesting specific attributes might decrease the number
> of cache hits.
>
> If we don't have a "tuning Shib and LDAP settings for max performance"
> page in the wiki, it might be a handy thing to have.
>
>> Also, remember that you can filter attribute values, which generally is useful to do if using this to release group information about a user.
>
> We use both techniques - scripted attributes that calculate
> eduPersonAffiliation/Entitlement well-known values on the fly based on a
> base attribute's values, and attribute filter policies that selectively
> release values to SPs based on what they actually need. This includes
> both exact matching (e.g. ePA value "member"), and regex matches (e.g.
> for an SP dept.umn.edu, release groups of the form
> "*,ou=Department,o=University of Minnesota,c=US").
>
> --
> %%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
> %%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
> %%  University of Minnesota    %%  +1 (612) 625-1809    %%
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net