Problem with attribute resolver

[Paul Hethmon]

A couple of thoughts:

1. What is your attribute filter doing? I'm thinking if you are not sending this other SP a name ID because none is defined it is simply redirecting back to the IdP.
2. Grab a copy of SAML Tracer for FF and use it to capture the SAML messages.

Paul


From: dave massie <dave.massie at gmail.com<mailto:dave.massie at gmail.com>>
Reply-To: Shibboleth Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Date: Monday, April 23, 2012 10:26 AM
To: Shibboleth Users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Problem with attribute resolver


Here is the problem. We are migrating users away from one mail system to another mail system. We want users who have NOT been officially migrated to the new mail system to be unable to access the new mail system. We want this behavior because we will be provisioning the users in the new system before we roll out the new system to the users.

OK. So, what we have done is to create a principal name for the new system:

  <!--  BEGIN GOOGLE NAME ID -->
    <resolver:AttributeDefinition id="GooglePrincipal" xsi:type="PrincipalName" xmlns="urn:mace:shibboleth:2.0:resolver:ad"
         sourceAttributeID="uid" >
         <resolver:Dependency ref="GoogleLDAP" />

              <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
                 xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                 nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />


    </resolver:AttributeDefinition >
  <!--  END GOOGLE NAME ID -->

And for the ldap query to get the principal name we have created an ldap connector called GoogleLDAP. Here it is:

<resolver:DataConnector xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
                        id="GoogleLDAP"
                        ldapURL="ldaps://directory.georgetown.edu<http://directory.georgetown.edu>"
                        baseDN="dc=georgetown,dc=edu"
                        principal="cn=uidWebMapping1,ou=Specials,dc=georgetown,dc=edu"
                        principalCredential="uidWebMapping"
                        noResultIsError="true">



    <FilterTemplate>
        <![CDATA[
            (&(uid=${requestContext.principalName})(|(guService=GUMail.GAE.Migration.Complete.*)(guService=GUMail.GAE.Migration.
Candidate)))
        ]]>
    </FilterTemplate>

Note that the query will return a value only when the guService attributes are correctly populated.

We have tested and people without the correct guService attributes are denied access. This is good.

However, when a person without the guService attributes tries to log into some other SP we get the error (from idp-process.log):

WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.AbstractSAML2ProfileHandler:465] - Error resolving at
tributes for principal 'dhm24'.  No name identifier or attribute statement will be included in response

The browser appears to be in a loop of some sort. I have not been able to see the url's because they are going by too fast.

Does anyone have any ideas as to what my problem is?

Thanks,

Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120423/1e9ed54a/attachment-0001.html