IDP proxing for vendors non-DS/Wayf capabilities

[Jehan PROCACCIA]

thanks Scott for the link https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration#AuthenticationConfiguration-AdvancedTopics 
I did permit Discovery Service to redirect to our Federation "switchWayf" DS service (Wayf.php) 
for the record, to do that I had to :
1) comment my previous test that redirected SSO to one specific IDP in authn/saml-authn-config.xml
 <!-- <bean id="shibboleth.authn.SAML.discoveryFunction" parent="shibboleth.Functions.Constant"
        c:target="https://upstreamIDP1/idp/shibboleth" /> -->
2) point authn.discoveryURL in authn/discovery-config.xml to the DS/WAYF URL 
 <bean id="shibboleth.authn.discoveryURL" class="java.lang.String"
        c:_0="https://shibds.domain.fr/wayfds/WAYF.php" />

I can tell that the subject is of IDP-proxy acting as a DS frontal to our schools upstreamIDP is resolved, thank you all !

I still have an issue regarding pass-through attributes, only the subject Princicpal is transmetted to the SP :

2021-02-04 09:13:52,451 -- DEBUG [net.shibboleth.idp.authn.impl.FinalizeAuthentication:118] - Profile Action FinalizeAuthentication: Canonical principal name was established as 'jehan.procaccia at imtbs-tsp.eu'
2021-02-04 09:13:52,500 - 157.159.52.132 - DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:139] - Attribute Definition 'uid': produced an attribute with the following values [StringAttributeValue{value=jehan.procaccia at imtbs-tsp.eu}]

But the other ones resolved before => eduPersonPrincipalName, eduPersonScopedAffiliation, uid ; 

2021-02-04 09:13:52,301 -- DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:153] - Attribute Filter Policy 'saml-proxy-pass-through'  Applying attribute filter policy to current set of attributes: [mail, eduPersonPrincipalName, eduPersonScopedAffiliation, uid]

got lost in the process . 

is it because of c14n/attribute canonicalization ? it takes only the Principal attribute I selected (mail)  in attribute-resolver.xml:  ? 

<AttributeDefinition id="canonicalName" xsi:type="SubjectDerivedAttribute"
    forCanonicalization="true"
    principalAttributeName="mail" />

or a pb with my attribute-filter ?

Nate, I'll probably come back later on (next weeks/mounth)  about the  discoveryFunctions you mention for "multi-tenant" applications, for my next shibboleth IDP integration (MS-365 ...) 

thanks.

----- Mail original -----
De: "Nate Klingenstein" <ndk at signet.id>
À: "users" <users at shibboleth.net>
Envoyé: Jeudi 4 Février 2021 18:06:50
Objet: RE: IDP proxing for vendors non-DS/Wayf capabilities

> The discoveryFunction is for functionally implementing something that doesn't need the user's input. Actual discovery is something you enable per login-flow and it will call to a discovery service first.

> https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration <https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration>, Advanced Topics.

We've written discoveryFunctions that work in a variety of ways.  The most common is to automatically route specific SP entityID's to specific IdP's so that discovery can be performed by vanity URL accessed(those "multi-tenant" applications) rather than by a DS interface.

It's a tremendously useful feature and thanks to the devs for creating it.

--------
Signet, Inc.
The Art of Access ®

https://www.signet.id

-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net