Using a different SP entity ID with the IdP SAML authn flow

[Wessel, Keith]

Hi, Jarno,

Yes, that's exactly what we're trying to do. We do plan to disable session persistence in the IdP when this is set up so that ADFS alone will be authoritative for the user's session. So, every authentication request will be proxied to ADFS, and ADFS will decide what the user needs to be prompted to do.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Jarno Huuskonen
Sent: Friday, September 3, 2021 2:48 AM
To: users at shibboleth.net
Subject: Re: Using a different SP entity ID with the IdP SAML authn flow

Hi,

On Thu, 2021-09-02 at 19:56 +0000, Wessel, Keith wrote:
> So, something like this?
> 
>     <bean id="proxySPEntityIDStrategy"
> parent="shibboleth.ContextFunctions.Scripted" factory- 
> method="inlineScript"
>         <constructor-arg>
>             <value>
>                 <![CDATA[
>                 spEntityID = 
> "https://urldefense.com/v3/__https://sp.example.org/shibboleth__;!!DZ3
> fjg!tnJeCWvfz8XHsB5QpOuRBLYFzM8CXa0MROWg-prPHndsKmqc4isXgzrHYRTx5Hr1qw
> $ ";
>                 authnCtxClassRef =
> input.getParent().getSubcontext(RequestedPrincipalContext.class);
> 
>                 if (authnCtxClassRef == 
> "https://urldefense.com/v3/__https://refeds.org/profile/mfa__;!!DZ3fjg
> !tnJeCWvfz8XHsB5QpOuRBLYFzM8CXa0MROWg-prPHndsKmqc4isXgzrHYRRfXL-BtQ$ 
> ") {
>                     spEntityID = 
> "https://urldefense.com/v3/__https://sp.example.org/shibboleth/mfa__;!
> !DZ3fjg!tnJeCWvfz8XHsB5QpOuRBLYFzM8CXa0MROWg-prPHndsKmqc4isXgzrHYRRRaM
> CLlA$ ";
>                 }
> 
>                 spEntityID;
>                 ]]>
>             </value>
>         </constructor-arg>
>     </bean>
> 
> Then use it like this:
> 
> <bean parent="RelyingPartyByName" c:relyingPartyIds="
> https://urldefense.com/v3/__https://adfs.example.org__;!!DZ3fjg!tnJeCWvfz8XHsB5QpOuRBLYFzM8CXa0MROWg-prPHndsKmqc4isXgzrHYRQxpssUOA$ "
>     responderIdLookupStrategy="proxySPEntityIDStrategy">
>     <property name="profileConfigurations">
>         <list>
>             <ref bean="SAML2.SSO">
>         </list>
>     </property>
> </bean>
> 
> Does that look sane? If it doesn't work, I'll certainly study the docs 
> for some of the objects I'm using to get the requested 
> authnContextClassRef since, as you stated, that's a rough guess.
> 

Are you trying to use MFA on ADFS(azuread ?) for some services and w/out MFA for other services ?

How does this interact with IdP sessions, if user logins to serviceA (w/out MFA requirement/entityID) and then logins to serviceB that requires MFA.

Does login to serviceB use valid/existing session(on IdP from serviceA
login) and skip MFA requirement for serviceB ? (Do you need to disable sessions on IdP for this?)

-Jarno

> Thanks,
> Keith
> 
> -----Original Message-----
> From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
> Sent: Thursday, September 2, 2021 2:25 PM
> To: Shib Users <users at shibboleth.net>
> Subject: Re: Using a different SP entity ID with the IdP SAML authn 
> flow
> 
> On 9/2/21, 3:04 PM, "users on behalf of Wessel, Keith" < 
> users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
> 
> >    Thanks, Scott. So, to make this dynamic and use a different SP 
> > entity ID based on, for example, authnContextClassRef of the 
> > original incoming request, I can create a bean and set the 
> > relyingPartyLookupStrategy on the specific relying party override 
> > bean to point to that bean. Is that correct?
> 
> I think you mean responderIdLookupStrategy (and if not, that's the 
> correct setting), but yes.
> 
> >    I assume my custom bean just returns a string with the entity ID 
> > that Shibboleth should identify itself as. Any pointers to other 
> > beans in the IdP configuration that would be a good example for me 
> > to base mine off of?
> 
> Nothing that would be relevant to looking at the AuthnRequest I can 
> think of, and this is much more tricky, you're talking about this 
> running when it's in the middle of proxying, so the tree is very messy at that point.
> Your function runs against a ProfileRequestContext that's sitting 
> underneath the AuthenticationContext, it's nested. You probably want 
> to base it on the cooked data, not the AuthnRequest.
> 
> input.getParent().getSubcontext(RequestedPrincipalContext.class) in 
> that lookup strategy call should actually go up and then back down to 
> where the requested context class(es) have been pulled out and stuffed 
> into the tree during authentication.
> 
> All of that could also be wrong, this is just a back of the envelope 
> guess.
> 
> -- Scott
> 
> 
> --
> For Consortium Member technical support, see 
> https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZY
> EpPw__;!!DZ3fjg!s7F3NKZ-taJgCWSGTGiCUljiQhHt4GqJZOKTioD6AWsTumcrO5L9AW
> FQeIMnCQmj6A$
>  
> To unsubscribe from this list send an email to 
> users-unsubscribe at shibboleth.net

--
Jarno Huuskonen
--
For Consortium Member technical support, see https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/x/ZYEpPw__;!!DZ3fjg!tnJeCWvfz8XHsB5QpOuRBLYFzM8CXa0MROWg-prPHndsKmqc4isXgzrHYRSWpmKjMQ$
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net