Different auth source depending on SP?

[Wessel, Keith]

Hi, all,

I haven't found a way to do this, but I figured I could be missing something.

We've got a use case where a specific SP that's hitting our proxy IdP needs to appear differently when the proxy sends the request to the downstream IdP. Specifically, when the proxy IdP sends the request on to the real IdP (which is entra, so authncontextClassRef won't work) we need entra to not perform MFA. I'm suspecting we'll need to:

1. Configure a second auth source with SimpleSAMLphp. This will be identical to our existing auth source whose SP metadata is registered with Entra other than the auth source name which will obviously create a different SP entity ID for connections proxied through this new auth source.
2. Register the new auth source's SP entity with Entra. As it'll be a new relying party registration, we can configure it to not require MFA.

The challenge is that I don't see a way to tell SimpleSAMLphp to use this alternate auth source for any request that's initiated from this specific SP. There's no way to tell the proxy IdP to use a different auth source depending on which SP sent the authn request. The only way I can figure out is to set up a second IdP entity ID in the saml20-idp-hosted.php that uses the alternate auth source then have the originating SP send its authn request to that IdP instead.

Is there a way to change auth source based on initiating SP?

Thanks,
Keith

[Tim van Dijen]

Hey Keith,

> Is there a way to change auth source based on initiating SP?

Not out of the box, but you could create your own authsource-selector based on https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/core/src/Auth/Source/AbstractSourceSelector.php
You can find examples there too.

- Tim

Op woensdag 16 september 2026 om 23:22:59 UTC+2 schreef Keith Wessel:

[Wessel, Keith]

Thanks, Tim. That looks doable. I might even base mine off of the SAML:SP auth source since that’s 99% of the way there. Can you suggest the easiest way to get the entity ID of the requesting SP inside the auth source code, though? That is, if the SP sends the authn request to my proxy IdP, how can I access the requesting SP’s entity ID from that authn request inside of my authentication source? Where would that be? I assume somewhere in the state object?

 

Keith

--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:
 
https://simplesamlphp.org/support
 
Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.
 
Make sure to read the documentation:
 
https://simplesamlphp.org/docs/stable/
 
If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:
 
http://catb.org/~esr/faqs/smart-questions.html
---
You received this message because you are subscribed to the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/simplesamlphp/0714c761-9026-457d-9c03-b0ae2f5e136cn%40googlegroups.com.

[pat...@cirrusidentity.com]

Hi Keith,

It sounds like your goal is to not send the authncontext in a request to one of the idps. If that is the only "appear different" criteria then you may have some other approaches.

Are you using `proxymode.passAuthnContextClassRef` to pass through the authncontexts requested by the original SP? I assume yes, since otherwise I'm unsure how you would get the described behavior.

I've just been discussing with Ioannis that section of the code, and use with refeds MFA, and part of what makes the code complicated is handling multiple distinct use cases with proxies, so knowing more about yours will be helpful as we look at Refeds MFA 2 enhancements.

In stock SSP, if you define a `AuthnContextClassRef` string setting in the remote idp's metadata, then I believe that takes precedence over anything requested by the original SP.
If setting a different context for Entra for all integrated SPs works, then you can do this approach. Entra's supported contexts are at https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol#requestedauthncontext . 

If your goal is to not send any AuthnContextClassRef, or to filter what you would send, or to only take the action based on what the original SP is, then I think your subclassing the SP class makes sense.

You can get the original SP entityId with `$state['core:SP']`

 If you override `startSSO` method then you can check if the selected IDP is entra, and if so unset `$state['saml:RequestedAuthnContext']`

- Patrick

[Wessel, Keith]

Thanks, Pat and Tim, this helped. We ended up using the RequestedAuthnSelector authentication source. Very clean and simple! We had to explicitly set the ACR in the Entra IdP metadata to unspecified. Otherwise, the proxy IdP tried to pass it through even with proxymode.passAuthnContextClassRef set to false. Not sure why, but it works fine.

 

We’ve got one related issue now, and I’m hoping someone can give me some guidance. In short, we need step-up authentication to work.

 

When an SP sends the special ACR context that I’ve created in our namespace to the proxy IdP, it sends the user to Entra with an app registration configured not to do MFA. If that ACR isn’t present from the originating SP, SimpleSAMLphp sends the user to a different Entra app registration that does require MFA. Let’s call them A and B in that order.

 

If the user logs into an SP using option A first, they get through Entra with just a password. If they then log into an SP using B, they already have a SimpleSAMLphp IdP session and thus don’t get sent back to Entra. They’ve now logged into an app that should require MFA but without doing MFA.

 

Our Shibboleth proxying to Entra sets the IdP session lifetime to 0 (actually one second since 0 isn’t allowed), making Entra authoritative for sessions. So,I thought let’s do the same in SimpleSAMLphp.

 

But when I tried setting session.duration to 0 or 1 in SimpleSAMLphp’s config.php, all sorts of weird things started to break. Seems like just going to Entra and back to the proxy IdP gave me unhandled exceptions from SimpleSAMLphp. Feels like session.duration controls a whole lot more than just the user’s IdP session lifetime. I’m also afraid that this would be a problem for propagating logouts on to the issuing IdP: a user signs in t something then later logs out of that service. The logout request goes to the proxy IdP, but if the session is no longer valid, SimpleSAMLphp doesn’t know what upstream IdP performed the original login so can’tsend them back to log them out.

 

Is there a way to tell SSP to limit the validity of the session lifetime while still keeping it around for other functions? Or even limit the lifetime of a session from a given authentication source so that the authentication source will at least always send the user to the upstream IdP? Or any other ways to get the user to always be sent to Entra so that step-up authentication can be performed if needed?

 

My last resort is to just stand up another proxy IdP instance to handle these no MFA logins. It would have a different everything, so there’d be no chance of someone getting in without doing MFA when they’re supposed to. But I’m trying to avoid that.

 

Thanks for any advice,

Keith

To view this discussion visit https://groups.google.com/d/msgid/simplesamlphp/ed6a9325-f133-42a6-96f9-641236ff6d8dn%40googlegroups.com.

[Wessel, Keith]

All,

 

I’ve been thinking about this more, and an idea that AI frighteningly suggested last week is starting to seem possibly attractive. Before I try it and see that it works but then discover five minutes after putting it into production that it was a terrible idea, I thought I’d ask here.

 

The suggestion was to add a PHP authproc filter either to the authsource or to the hosted IdP metadata that manipulated the session expiration time in the state object, setting it to a few seconds from the current time. This would definitely solve the issue of the session sticking around and should allow for step-up authentication. But will it break propagating logout to the requesting IdP? In other words, if I set the session expiration time to a few seconds from now then the user gets sent back to the proxy IdP’s logout endpoint an hour later, will the proxy IdP still know anything about that session so that it can send the logout request on to the upstream IdP?

 

And is manipulating the session expiration in the state object any different than setting the session duration in config.php to a low value?

 

Thanks,

Keith

[pat...@cirrusidentity.com]

Hmm, looks like AbstractSourceSelector/RequestedAuthnSelector doesn't cover the reauth scenario wanting to pick a different authsource.

We've set a short session time as part of authprocs to handle users that we wanted to clear their session and have them re-auth. We did it by setting their session cookie to expire in 3 seconds. I'm sure there is a large variety of ways to do it, through with our case logout definitely doesn't propagate.

- Patrick

[Tim van Dijen]

Hi Keith,

I think the setting you're looking for is this:
https://github.com/simplesamlphp/simplesamlphp/blob/master/config/config.php.dist#L612

I think it should work if you set that one to `1`.

- Tim

Op woensdag 30 september 2026 om 18:58:59 UTC+2 schreef pat...@cirrusidentity.com: