IDP proxing for vendors non-DS/Wayf capabilities

Wed Feb 3 14:22:32 UTC 2021

Thanks Nate, I'am getting closer to an operational solution ! 
from the basic workflow describe in the doc: https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP#UsingSAMLProxyingtoanotherIdP-Basicworkflow
I reached  step 6 ;-) 

Yesterday problem about "No metadata returned for https://upstreamIDP..." was my fault, I had in my IDPproxy metadata-providers.xml a filter to load our federation  SPs only ! (<RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> )

Now when I connect to my "test Vendor SP" , I am well redirected from IDPproxy to upstreamIDP (here's IDPproxy logs): 

2021-02-03 11:06:48,270 -  - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.AddAuthnRequest:219] - Profile Action AddAuthnRequest: Setting Issuer to https://idpproxy.imtbs-tsp.eu/idp/shibboleth
2021-02-03 11:06:48,291 - - INFO [Shibboleth-Audit.SSO:282] - ||2021-02-03T10:06:48.290326Z||https://upstreamIDP.domain.fr/idp/shibboleth||||||||false||POST||||||

>From here, the user fill in the login form on upstreamIDP, and after sucess Login on upstreamIDP , IDPproxy does receive an SAML assertion with an uid and transcient ID (I guess) here's the upstreamIDP logs: 

Then back to IDPproxy logs I do get the SAML assertion from upstreamIDP and do see the uid attribute beeing transmitted bratween upstreamIDP and IDPproxy which I detail from the logs in each step beacuse this with this uid<->pricipal that it fails now :

2021-02-03 11:07:22,063 - - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:384] - Profile Action ValidateSAMLAuthentication: Decoding incoming SAML Attributes
2021-02-03 11:07:22,066 -  - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:414] - Profile Action ValidateSAMLAuthentication: Incoming SAML Attributes mapped to attribute IDs: [uid]
2021-02-03 11:07:22,077 - - DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:153] - Attribute Filter Policy 'Per-Attribute-singleValued'  Applying attribute filter policy to current set of attributes: [uid]
...

then IDPproxy correctly choose Attribute Filter Policy "saml-proxy-pass-through" as defined in attribute-filter.xml

<AttributeFilterPolicy id="saml-proxy-pass-through">
            <PolicyRequirementRule xsi:type="Issuer" value="https://upstreamIDP.domain.fr/idp/shibboleth" />
                <AttributeRule attributeID="uid" permitAny="true" />
    </AttributeFilterPolicy>

IDPproxy  process that Filter

2021-02-03 11:07:22,080 - - DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:119] - Attribute Filter Policy 'saml-proxy-pass-through'  Checking if attribute filter policy is active
2021-02-03 11:07:22,081 - - DEBUG [net.shibboleth.idp.attribute.filter.AttributeFilterPolicy:153] - Attribute Filter Policy 'saml-proxy-pass-through'  Applying attribute filter policy to current set of attributes: [uid]
2021-02-03 11:07:22,082 - - DEBUG [net.shibboleth.idp.attribute.filter.impl.AttributeFilterImpl:178] - Attribute filtering engine 'ShibbolethAttributeFilter': 1 values for attribute 'uid' remained after filtering

Then the subject , apparently it takes 2 canonicalization attribute (uid and transcient ID ?) 

2021-02-03 11:07:22,084 - - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:302] - Profile Action ValidateSAMLAuthentication: Added translated AuthnContext Principals: [urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport]
2021-02-03 11:07:22,085 - - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:325] - Profile Action ValidateSAMLAuthentication: Adding filtered inbound attributes to Subject
2021-02-03 11:07:22,088 -- DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ValidateSAMLAuthentication:277] - Profile Action ValidateSAMLAuthentication: Resetting authentication time to proxied value: 2021-02-03T10:07:08.443Z
2021-02-03 11:07:22,120 - - DEBUG [net.shibboleth.idp.authn.impl.PopulateSubjectCanonicalizationContext:75] - Profile Action PopulateSubjectCanonicalizationContext: Installing 2 canonicalization flows into SubjectCanonicalizationContext

and finally here it fails with Canonicalization flow c14n which fails on SelectSubjectCanonicalizationFlow

2021-02-03 11:07:22,161 - - DEBUG [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:106] - Profile Action SelectSubjectCanonicalizationFlow: Canonicalization flow c14n/simple was not applicable to this request
2021-02-03 11:07:22,161 - - ERROR [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:78] - Profile Action SelectSubjectCanonicalizationFlow: No potential flows left to choose from, canonicalization will fail

2021-02-03 11:07:22,162 - - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:142] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SAML to intermediate set
2021-02-03 11:07:22,163 - - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:316] - Profile Action SelectAuthenticationFlow: No potential flows left to choose from, authentication failed

I suspect that the Canonicalization is wrong, where did I missed something ? 
on the IDPproxy filter/Canonicalization or on the upstreamIDP sent attribute / nameID ? 

Thanks .

----- Mail original -----
De: "Nate Klingenstein" <ndk at signet.id>
À: "users" <users at shibboleth.net>, "users" <users at shibboleth.net>
Envoyé: Mardi 2 Février 2021 22:25:35
Objet: RE: IDP proxing for vendors non-DS/Wayf capabilities

Jehan,

> 1) No metadata returned for https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth> in role {urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol

Exactly.  Of course, the proxy will need to load and trust the upstream IdP's metadata.  You can do that as part of the federation aggregation or just load it as a separate file, but it must be trusted.

> 2) Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser <http://shibboleth.net/ns/profiles/saml2/sso/browser> is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth>)

This is just saying that you're not running a totally open proxy that will accept assertions from anyone and is a relic from error #1.

It's good that you manage the federation metadata that way.  InCommon has(had?  Haven't been following patch notes) a confining interface that wouldn't permit this easily, requiring you to register either an IdP or an SP using a GUI.

Your discoveryFunction bean is fine, but it will of course need to be modified when it actually does discovery.

Take care,
Nate.

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

https://www.signet.id

-----Original message-----
From: Jehan PROCACCIA
Sent: Tuesday, February 2 2021, 2:19 pm
To: users
Subject: Re: IDP proxing for vendors non-DS/Wayf capabilities

I manage my federation Metadata myself with those tools : xmlsectool and aggregator-cli

So I published in our schools Federation the entityID of my IDPproxy with only the elements <SPSSODescriptor...  (no IDP elements) 
and loaded on a test SP (representing the Vendor SP) only the  <IDPSSODescriptor of my IDPproxy
so that SP metadata and the IDP metadata of the same entityID (IDPproxy) appears in different files and not cross loaded on Vendor SP and upstream IDPs
Then everything seems clear now regarding metadata
unfortunatly while connecting to Vendor SP , I am redirected to IDPproxy and there it fails with  :

opensaml::FatalProfileException
The system encountered an error at Tue Feb 2 21:43:14 2021

opensaml::FatalProfileException at (https://vendorSP.domain.fr/Shibboleth.sso/SAML2/POST <https://vendorSP.domain.fr/Shibboleth.sso/SAML2/POST>)

SAML response reported an IdP error.

Error from identity provider:

Status: urn:oasis:names:tc:SAML:2.0:status:Requester
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
Message: An error occurred.

IDPproxy logs shows :

2021-02-02 21:43:14,439 - - INFO [org.opensaml.saml.common.binding.impl.SAMLMetadataLookupHandler:167] - Message Handler:  No metadata returned for https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth> in role {urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol
2021-02-02 21:43:14,440 -- DEBUG [net.shibboleth.idp.saml.profile.impl.InitializeRelyingPartyContextFromSAMLPeer:131] - Profile Action InitializeRelyingPartyContextFromSAMLPeer: Attaching RelyingPartyContext based on SAML peer https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth>
2021-02-02 21:43:14,440 - - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:249] - Resolving relying party configuration
2021-02-02 21:43:14,441 - - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:255] - Profile request is unverified, returning configuration shibboleth.UnverifiedRelyingParty
2021-02-02 21:43:14,441 - - DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:136] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration shibboleth.UnverifiedRelyingParty for request
2021-02-02 21:43:14,442 -  - WARN [net.shibboleth.idp.profile.impl.SelectProfileConfiguration:118] - Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser <http://shibboleth.net/ns/profiles/saml2/sso/browser> is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth>)
2021-02-02 21:43:14,444 -  - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:142] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SAML to intermediate set
2021-02-02 21:43:14,444 -  - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:274] - Profile Action SelectAuthenticationFlow: No specific Principals requested
2021-02-02 21:43:14,445 -  - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:312] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
2021-02-02 21:43:14,445 -  - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:316] - Profile Action SelectAuthenticationFlow: No potential flows left to choose from, authentication failed

I guess the problem is related to those 2 messages

1) No metadata returned for https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth> in role {urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor with protocol urn:oasis:names:tc:SAML:2.0:protocol
2) Profile Action SelectProfileConfiguration: Profile http://shibboleth.net/ns/profiles/saml2/sso/browser <http://shibboleth.net/ns/profiles/saml2/sso/browser> is not available for RP configuration shibboleth.UnverifiedRelyingParty (RPID https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth>)

Do you have an idea of what could be wrong here ?

I did followed https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP <https://wiki.shibboleth.net/confluence/display/KB/Using+SAML+Proxying+to+another+IdP>
specifically adding in conf/authn/saml-authn-config.xml

  <bean id="shibboleth.authn.SAML.discoveryFunction" parent="shibboleth.Functions.Constant"
        c:target="https://upstreamIDP.domain.fr/idp/shibboleth <https://upstreamIDP.domain.fr/idp/shibboleth>" />

thanks .
-- 
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