Fetch Attributes From SAML IdP

[Saurabh Tyagi]

Thank you David.

So the problem that I am afacing is due to Wrong config of LDAP in
Attribute-Resolver?

Thanks and Regards
Saurabh Tyagi


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


(Since we're top-posting):

I just set up shib idp also, and I know the answer to your first question:

The transientId is a NameId, and hence goes in the <Subject> of the 
assertion.  It is not an attribute, so it is correct to say that there 
are no attributes (and no attribute statetment will be added to the 
assertion).

Regarding the second question, to see the XML of the assertion (assuming 
a shib. SP) you need two things:

1) disable the encryption of the assertion in relying-party.xml by 
setting encryptAssertions="never"
2) enable DEBUG logging in shibd on the sp in shibd.logger file, uncomment:

log4j.category.OpenSAML.MessageDecoder=DEBUG

Be sure to restart all necessary components.

Thanks,
David Mansfield


On 06/27/2013 11:12 AM, Saurabh Tyagi wrote:
> 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
>
>
>
> --
> To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net