Order of events after a proxied authentication

[Wessel, Keith]

Thanks, Scott. I didn't think about how Microsoft was actually doing comparisons on the requested context. You're right about that. Returning password, though... that's quite strange, though.

Since I've already got a bean that's returning the MFA context if the right claim is present and, otherwise, just passing through the authn context asserted by Azure, checking to see if it's password and adding PPT in that case seems straightforward enough.

One question, though. You say I can return both password and PPT. My understanding is that the translation strategy has to return a singleton list. How can I return two authn context class refs if a singleton list can only contain one?

Thanks,
Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, September 6, 2022 8:12 AM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Order of events after a proxied authentication

On 9/2/22, 1:01 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    If I pass PPT through from the originating SP to Azure and the user is
> logged in with WindowsIntegratedAuth, Azure breaks. That's probably an
> Azure bug.

No, that's the rare case of them not doing the wrong thing for a change.

> At the least, Microsoft should prompt the user for password auth. Better
> yet, they might say that WindowsIntegratedAuth is more secure than
> password and thus also satisfies password, and so they could make
> everyone happy by returning what was requested.

They don't get to do that unless the SP requests minimum or better.

>    Microsoft, amusingly enough, returns password to the IdP when I do this.
> It won't allow password or PPT in the request to satisfy a condition with a
> user logged in with windows integrated auth, but it will return it.

That is of course lying, which is effectively disqualifying for an IdP.

> But we still have a problem if the SP requests PPT. I'm trying to work around
> this until Microsoft fixes this (if they ever do). The problem is the IdP gets
> back password and says that it can't satisfy the request for PPT.

You can always map Password to PPT across the boundary going back so that receiving Password will cause the proxy to assert PPT, and then the original SP will work.

But you built your own function to do that mapping, so you would have to do that mapping as well.

>    Do I need to manually code around this in the authn context translation
> strategy bean by checking what the SP requested and, if PPT, manually
> setting the authn context in the response to PPT?

You can map Password or PPT to "both" on the way back so the Subject always includes both and SPs that request either one will be happy.

> Or is there some plumbing somewhere in the IdP that lets me say password
> and PPT are equivalent, thus letting it automatically do the translation?

Yes, but you're subverting that by doing the mapping yourself. As I probably said at some point, you could also inject the proxy response mapping "map" into your function as a custom object and leverage it in some way as well as whatever your custom code is doing for you.

-- Scott