users Digest, Vol 33, Issue 42

Josh Christensen jchristensen at ftni.com
Fri Mar 14 17:16:21 EDT 2014


All logging is enabled and set to debug level.

On your suggestion, I changed my attribute map to:

<Attribute name="email" id="email" />

Then I ran through the login process.  Then, I searched the logs for "email".  There is only 1 hit.

2014-03-14 16:05:13 DEBUG Shibboleth.PropertySet : added property REMOTE_USER (eppn persistent-id targeted-id email)

It still is not pulling the e-mail out of the data.  The company that does the IDP (not my company) is using this for their method of passing the data.  I have no say in the matter.  I just need to get this to work.

Date: Fri, 14 Mar 2014 20:57:44 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: Having trouble with my configuration
To: Shib Users <users at shibboleth.net>
Message-ID: <CF48E421.4B8BB%cantor.2 at osu.edu>
Content-Type: text/plain; charset="Windows-1252"

On 3/14/14, 3:53 PM, "Josh Christensen" <jchristensen at ftni.com> wrote:

>I have the service running.  It stops at starts without issue.  We have 
>IDP-initiated working in that the user signs in at the IDP (an external 
>server not running shibboleth), and the user is sent to our test page 
>where we write out information  about the request in an effort to 
>figure out where the data is stored for retrieval and authentication on 
>our site.
> 
>The logs have no errors.

It may not have errors, but there will be evidence that it's processing the incoming assertion response and what it's doing with it, and it will warn about anything it's not processing. And you can turn up logging of course.

> 
>                  
>     <ds:X509Certificate>
>                  
>                      <!?removed for security reasons -->
>                  
>      </ds:X509Certificate>

A certificate is public data, there are no such reasons.

>Originally, there was an EntityConfig section following the 
>EntityDescriptor closing tag, but that cause the service to error on 
>startup, so I commented it out.  Here is what it looks like.

That isn't valid SAML metadata. Unless it's in an Extensions element, the SP will not process that, no.

>I am at a loss with what to do with this.  The documentation is not 
>clear on this section or what to do with it.

It has no relevance whatsoever, and certainly has nothing to do with Shibboleth.

> 
>In my attribute-map.xml, I have tried several different ways of mapping 
>the attributes and none are being picked up.

Well, noting you posted matches what's in the assertion.

For example:

><!-- Comapny email attribute -->
><Attribute name="urn:sun:fm:SAML:2.0:entityconfig:email" id="email" />

I see no such named attribute. I do see:
>
>        <saml:AttributeStatement>
>            <saml:Attribute FriendlyName="email" Name="email">

That is a lousy way to carry federated data, but that aside, the name of that attribute is "email". Not "urn:sun:fm:SAML:2.0:entityconfig:email"

But your logs will tell you that it's skipping the actual attribute(s) in the assertion as unmapped. If not, you're not looking at the actual log.

-- Scott




------------------------------

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

End of users Digest, Vol 33, Issue 42
*************************************


More information about the users mailing list