| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
docpublic:systemes:shibboleth:idpproxy [2021/06/09 09:42]
adminjp [IDPSSODescriptor] |
docpublic:systemes:shibboleth:idpproxy [2021/06/09 15:07] (current)
adminjp [pass-though attributes] |
| </code> | </code> |
| |
| | ===== use SAML flow ===== |
| | |
| | tell the IDP (in conf/idp.properties) to use the SAML flow |
| | |
| | <code> |
| | #idp.authn.flows=Password |
| | idp.authn.flows=SAML |
| | </code> |
| | |
| | ref: https://wiki.shibboleth.net/confluence/display/IDP4/SAMLAuthnConfiguration |
| | ===== IDPproxy Discovery Service / WAYF ===== |
| | |
| | ref : https://wiki.shibboleth.net/confluence/display/IDP4/AuthenticationConfiguration#AuthenticationConfiguration-AdvancedTopics |
| | |
| | permit Discovery Service to redirect to our Federation "switchWayf" DS service (Wayf.php) |
| | |
| | |
| | 1) comment my previous test that redirected SSO to one specific IDP in authn/saml-authn-config.xml |
| | <code> <!-- <bean id="shibboleth.authn.SAML.discoveryFunction" parent="shibboleth.Functions.Constant" |
| | c:target="https://upstreamIDP1/idp/shibboleth" /> --></code> |
| | |
| | 2) point authn.discoveryURL in authn/discovery-config.xml to the DS/WAYF URL |
| | <code> <bean id="shibboleth.authn.discoveryURL" class="java.lang.String" |
| | c:_0="https://shibds.domain.fr/wayfds/WAYF.php" /></code> |
| | |
| | ===== Subject Principal ===== |
| | |
| | from : https://wiki.shibboleth.net/confluence/display/IDP4/SAMLAuthnConfiguration |
| | |
| | to resume Subject Canonicalization sub chapter of that doc: |
| | |
| | // "there is a requirement to process the AuthenticationResult into a normalized principal name,...this isn't a trivial thing to do. there is no simple "username" to rely on and the system requires some dedicated configuration to know what to do."// |
| | |
| | So I followed the doc by defining in attribute-resolver.xml the mail attribute as beeing of type="SubjectDerivedAttribute": |
| | |
| | <code> |
| | <AttributeDefinition id="canonicalName" xsi:type="SubjectDerivedAttribute" |
| | forCanonicalization="true" principalAttributeName="mail" /> |
| | </code> |
| | then select mail from my upstreamIDP issuer in attribute-filter.xml |
| | |
| | <code> |
| | <PolicyRequirementRule xsi:type="Issuer" value="https://upstreamIDP.domain.fr/idp/shibboleth" /> |
| | <AttributeRule attributeID="mail" permitAny="true" /> |
| | </code> |
| | |
| | then , enabling post-Login c14n flow in subject-c14n.xml : <bean id="c14n/attribute" parent="shibboleth.PostLoginSubjectCanonicalizationFlow" /> |
| | |
| | Finaly associate the id=canonicalName for "the list of attributes to resolve for normalizing the subject" in attribute-sourced-subject-c14n-config.xml |
| | |
| | <code> |
| | <util:list id="shibboleth.c14n.attribute.AttributesToResolve"> |
| | <value>canonicalName</value> |
| | </util:list> |
| | |
| | <util:list id="shibboleth.c14n.attribute.AttributeSourceIds"> |
| | <value>canonicalName</value> |
| | </util:list> |
| | </code> |
| | |
| | Now the canonicalization process does include the c14n/attribute flow, see logs below with 3 canonicalization flows (there were the 2 defaults before; c14n/x500 and c14n/simple) |
| | |
| | <code> |
| | 2021-02-03 22:41:08,282 -- DEBUG [net.shibboleth.idp.authn.impl.PopulateSubjectCanonicalizationContext:75] - Profile Action PopulateSubjectCanonicalizationContext: Installing 3 canonicalization flows into SubjectCanonicalizationContext |
| | </code> |
| | |
| | Then I can see that the mail attribute seems well passThrough upstreamIDP to IDPproxy by my "canonicalName" attribute definition: |
| | |
| | <code> |
| | 2021-02-03 22:41:08,397 -- DEBUG [net.shibboleth.idp.attribute.resolver.ad.impl.ContextDerivedAttributeDefinition:179] - SubjectDerivedAttributeDefinition canonicalName Generated 1 values |
| | 2021-02-03 22:41:08,398 -- DEBUG [net.shibboleth.idp.attribute.resolver.AbstractAttributeDefinition:139] - Attribute Definition 'canonicalName': produced an attribute with the following values [StringAttributeValue{value=jehan.procaccia@imtbs-tsp.eu}] |
| | 2021-02-03 22:41:08,400 -- DEBUG [net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl:519] - Attribute Resolver 'ShibbolethAttributeResolver': Attribute 'canonicalName' has 1 values after post-processing |
| | </code> |
| | |
| | but then, next log line, it fails : |
| | |
| | <code> |
| | 2021-02-03 22:41:08,408 -- ERROR [net.shibboleth.idp.authn:-2] - Uncaught runtime exception |
| | java.lang.NullPointerException: null |
| | at net.shibboleth.idp.attribute.resolver.impl.AttributeResolverImpl.collectExportingDataConnectors(AttributeResolverImpl.java:542) |
| | 2021-02-03 22:41:08,413 -- INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:142] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SAML to intermediate set |
| | </code> |
| | |
| | That was a bug in 4.0.1, shib-user list responded : // you can't use the exporting feature with connectors that produce no data until it's fixed. Just don't do the exporting trick for now if they occasionally produce no results.// |
| | |
| | Indeed , I don't use ldap attributes in the context of the IDPProxy, it just pass-through attributes sent from upstreamIDPs, |
| | so remove "myLDAP" Data connector from attribute-resolver.xml as it not necessary in that context (which produced no value, and hence the bug) |
| | |
| | then back to idp-preocess.log, the flow continues : |
| | |
| | <code> |
| | 2021-02-04 09:13:52,444 -- DEBUG [net.shibboleth.idp.authn.impl.AttributeSourcedSubjectCanonicalization:171] - Profile Action AttributeSourcedSubjectCanonicalization: Using attribute canonicalName string value jehan.procaccia@imtbs-tsp.eu as input to transforms |
| | 2021-02-04 09:13:52,445 -- DEBUG [net.shibboleth.idp.authn.AbstractSubjectCanonicalizationAction:218] - Profile Action AttributeSourcedSubjectCanonicalization: trimming whitespace of input string 'jehan.procaccia@imtbs-tsp.eu' |
| | 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@imtbs-tsp.eu' |
| | 2021-02-04 09:13:52,456 -- DEBUG [net.shibboleth.idp.session.impl.UpdateSessionWithAuthenticationResult:222] - Profile Action UpdateSessionWithAuthenticationResult: Creating new session for principal jehan.procaccia@imtbs-tsp.eu |
| | </code> |
| | |
| | ===== pass-though attributes ===== |
| | |
| | ThenI encontered an issue regarding pass-through attributes, only the subject Princicpal was transmetted to the SP : |
| | |
| | <code> |
| | 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@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@imtbs-tsp.eu}] |
| | </code> |
| | |
| | But the other ones resolved before => eduPersonPrincipalName, eduPersonScopedAffiliation, uid ; |
| | |
| | <code> |
| | 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] |
| | </code> |
| | |
| | got lost in the process . |
| | |
| | The solution was in the Doc : https://wiki.shibboleth.net/confluence/display/IDP4/SubjectDataConnector |
| | |
| | A new dataConnector for the IPD-proxy (attribute-resolver.xml) was needed : |
| | |
| | <code> |
| | <DataConnector id="passthroughAttributes" xsi:type="Subject" exportAttributes="mail givenName sn eduPersonAffiliation eduPersonPrincipalName" /> |
| | </code> |
| | |
| | there is no need to add to that Dataconnector a derivated AttributeDefinition , which I've done in the 1st place but then commented and it still worked fine |
| | |
| | :!: not needed :!: |
| | <code> |
| | <!-- <AttributeDefinition xsi:type="Simple" id="sn"> |
| | <InputDataConnector ref="passthroughAttributes" attributeNames="sn" /> |
| | </AttributeDefinition> --> |
| | </code> |
| | |
| | |
| | ===== Raw shibboleth-users ML threads ===== |
| | |
| | All this was possible thanks to the Mailing list shibboleth-users , cf this thread for details |
| | * https://marc.info/?t=161193758600001&r=1&w=2 |
