Fetch Attributes From SAML IdP
Peter Schober
peter.schober at univie.ac.at
Thu Jun 27 10:45:23 EDT 2013
* Saurabh Tyagi <saurabh.tyagi at thepsi.com> [2013-06-27 16:24]:
> I have made changes back to original in Attribute_resolver.
>
> resolver:AttributeDefinition xsi:type="ad:TransientId" id="transientId">
>
> <resolver:AttributeEncoder xsi:type="enc:SAML1StringNameIdentifier"
> nameFormat="urn:mace:shibboleth:1.0:nameIdentifier"/>
>
> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID"
> nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
>
> </resolver:AttributeDefinition>
>
> and now Just having filter in
>
> Attribute Filter.
>
> <afp:AttributeRule attributeID="transientId">
>
> <afp:PermitValueRule xsi:type="basic:ANY"/>
>
> </afp:AttributeRule>
You do have an AttributeFilterPolicy around that, just like in the
default configuration?
Like I said, the config installed by default is correct for Transient
Ids. Everything else is you breaking that.
> Still getting Attribute transientId was not encoded because no
> SAML2AttributeEncoder was attached to it.
Given than this is a specific name format for a NameID (not a SAML
attribute) it does not have an attribute encoder atatched to it.
This is not an error message, just DEBUG logging.
> My Ldap Config that are working fine in Login.config are (I am
> succesfully loggin in using them)
>
> ldapUrl="ldap://192.168.0.138"
> baseDn="CN=Users,DC=fcsjpr,DC=com"
> bindDn="CryoserverJournal"
> bindCredential="jpr0123"
> subtreeSearch="true"
> ssl="false"
> userField="userPrincipalName";
I sure hope that is not a real password (even though you're on a
private network). But then all data flows in the clear here (no
TLS/SSL) so maybe that's irrelevant. People on that network will see
the password anway.
> Below is the Setting that I am using in attribute resolver.
>
> <resolver:DataConnector id="myLDAP" xsi:type="dc:LDAPDirectory"
> ldapURL="ldap://192.168.0.138"
> baseDN="cn=Users,dc=fcsjpr,dc=com"
> principal="cn=CryoserverJournal,cn=Users,dc=fcsjpr,dc=com"
> principalCredential=" jpr0123"
> lowercaseAttributeNames = "true"
> >
> <dc:FilterTemplate>
> <![CDATA[
> (cn=${requestContext.principalName})
> ]]>
> </dc:FilterTemplate>
> </resolver:DataConnector>
Well, before you sent files with a baseDN of cn=Users,dc=jpr,dc=com
and the RDN attribute was "uid". In your JAAS login.conf above you now
have a another baseDN and "userPrincipalName" instead, and in the
attribute resolver "cn".
I cannot know what is right in your case but I would assume that using
the exact same values which work for authentication via JAAS will work
for attribute resolving (i.e.,
userPrincipalName=${requestContext.principalName} instead of cn=...).
-peter
More information about the users
mailing list