Fetch Attributes From SAML IdP

[Saurabh Tyagi]

Thanksa lot Peter. Ur helping a lot.
I have no words how grateful I am to you.


But if u see logs 
First ot says " Attribute transientId has 1 values after filtering "
and in last line it says " No attributes remained after encoding and
filtering by value, no attribute statement built ",

It should pass atleast the transientId. 

I was looking for an alternate.While i was stuck in this.
I changed includeAttributeStatement to true (xsi:type="saml:SAML2SSOProfile"
includeAttributeStatement="true") so that I can get Ldap values as user
loggin.
How can I access/check these values @ SP.


Thanks and Regards
Saurabh Tyagi


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On
Behalf Of Peter Schober
Sent: Thursday, June 27, 2013 8:15 PM
To: users at shibboleth.net
Subject: Re: Fetch Attributes From SAML IdP

* 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
--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net