Having trouble with my configuration

[Cantor, Scott]

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