delegation in IDP3

[Robert A Basch]

Ah, thanks to you both.  I had glanced at the subject-c14n.xml file earlier,
and just noted that emailAddress was supported, not noticing that the SPs
for which mapping is enabled had to be enumerated as well, which makes
perfect sense.  I added that, configured the relying party to issue an
ID populated from the uid attribute (to avoid having to transform the
value, as with the netid example), added its format to the "direct
transformations" list, and the IdP then issued a delegated assertion.

I did see a new error in the log, appearing twice in succession just
before the audit line for the assertion:

    ERROR [org.opensaml.storage.impl.client.ClientStorageService:451] -
      StorageService shibboleth.ClientSessionStorageService: No storage
      object found in session

But the assertion seemed to be correct, and authentication was apparently
successful when the assertion was posted to the back-end service.  I'm
guessing this error has to do with the client not supporting the session
cookie, and that this storage is not useful in this case anyway.

I need to do more testing, etc., but we may be able to live with this
work-around.

Thanks again.

Bob



> On Aug 10, 2016, at 6:00 PM, Brent Putman <putmanb at georgetown.edu> wrote:
> 
> 
> 
> On 8/10/16 5:22 PM, Cantor, Scott wrote:
>> 
>> It won't do that for you unless you tell it to support emailAddress format.
>> 
>> 
>> https://wiki.shibboleth.net/confluence/display/IDP30/NameIDConsumptionConfiguration
>> 
>> 
>> If you did that, 
>> 
> 
> For the record, in my testing I did do that, and it worked for me.  Part of my conf/c14n/subject-c14n.xml looks like the following.  I added the 'urn:test:netid' format to support direct transform of that (made up) format, as well as the entityIDs to the list in the predicate to allow its use for them.
> 
> 
>     <!-- What SAML NameID formats do you want to support direct transformations for? -->
>     <util:list id="shibboleth.NameTransformFormats">
>         <value>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</value>
>         <value>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</value>
>         <value>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</value>
>         <value>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</value>
>         <value>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</value>
>         <value>urn:test:netid</value>
>     </util:list>
> 
>     <!--
>     Under what conditions should direct NameID mapping be allowed? By default, never.
>     Any condition can be used here; the example is suitable for enumerating a number of SPs to allow.
>     -->
>     <bean id="shibboleth.NameTransformPredicate" parent="shibboleth.Conditions.RelyingPartyId">
>         <constructor-arg>
>             <util:list>
>                 <!-- <value>https://sp.example.org</value> -->
>                 <value>https://sp.example.org/shibboleth</value>
>                 <value>https://portal.example.edu/shibboleth</value>
>                 <value>https://service.example.com/shibboleth</value>
>             </util:list>
>         </constructor-arg>
>     </bean>
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net