[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: Problems using FEIDE as IdP with shibboleth
From:       Peter Schober <peter.schober () univie ! ac ! at>
Date:       2016-03-29 10:22:03
Message-ID: 20160329102202.GO19117 () aco ! net
[Download RAW message or body]

* Lars Slettjord <lars.slettjord@uit.no> [2016-03-29 08:38]:
>   Problem with Identity Provider The SAML assertion for "eppn" was
>   null. Please contact support.

That doesn't sound like it's coming from the Shib SP but from your
application. Anyway: Try setting showAttributeValues="true" in your
Shib SP and have a look at /Shibboleth.sso/Session after another login
attempt. Maybe something about the ePPN value will stand out to you.
Or log on DEBUG and look at the SAML assertion itself.

If the ePPN actually was null (i.e., has an empty string as its value,
the closest thing to a null value that's likely to be included) I'm
not sure that's legal, but in any way sending empty strings as SAML
attributes doesn't make a lot of sense to me. But first you'll need to
figure out what the actual value is.

> I get the following attributes from FEIDE:
> 
> * eduPersonPrincipalName
> * givenName
> * mail
> * sn

I'm assuming that's from your transaction.log? Any other log entries
in shibd*.log at that time? Warnings, "skipping" messages?

>  <MetadataProvider type="XML"
>   uri="https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php"
>   backingFilePath="local-idp-metadata.xml"
>   legacyOrgNames="true"
>   reloadInterval="7200"/>

There is no security in any this, of course, without a MetadataFilter
of type "Signature". You're just loading plain text files over the
Internet and treating the content like CA certificates. So don't do that.

> And attribute-map.xml as suggested by FEIDE like this:
> 
>  <Attribute name="eduPersonPrincipalName" id="eppn"
>            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
>     <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>  </Attribute>

That's probably OK, even though it violates both the SAML Profile for
eduPerson attributes[1] as well as saml2int[2], which all require URI
nameFormat, not basic.
[1] http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf
[2] http://saml2int.org/profile/current/#section7

At least you could check whether the FEIDE IDP /also/ releases URI
names, in which case you could use those and forget about the custom
rules and basic names.

>  <Attribute name="givenName" id="givenName"
>            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
>     <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>  </Attribute>
> 
>  <Attribute name="sn" id="sn"
>            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
>     <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>  </Attribute>
> 
>  <Attribute name="mail" id="mail"
>            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
>     <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>  </Attribute>
> 
>  <Attribute name="email" id="email"
>            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
>     <AttributeDecoder xsi:type="ScopedAttributeDecoder"/>
>  </Attribute>

None of these attributes are "scoped" in the SAML sense, so all those
AttributeDecoder child elements are wrong and unnecessary. So none of
these should have any values after processing (which is a good as not
having them defined in your map at all, I guess).
The application is complaining about a null ePPN, though, which is
defined to be scoped (so the above config is appropriate). So that's
still to be solved.
-peter
-- 
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]