idp auth module plugin

[Cantor, Scott]

On 7/18/22, 10:30 PM, "dev on behalf of Paul Henson" <dev-bounces at shibboleth.net on behalf of henson at signet.id> wrote:

>    Am I missing something else? That doesn't seem like "a lot" of defaults :).

You're not missing anything.

>    Hmm, I'm not quite catching that. There's only going to be one
>    integration, defined by the URL to what rapid identity server to use.

If that's true, there must be other content in the requests that drives policy, which would just move the problem to that stage.

> The API uses
>    cookies in addition to a rest protocol level session identifier so I'm 
>    going to need to persist cookie state across requests too.

That's much trickier. We've never done it, the state challenges are very big. I don't know how that would or could be done. Probably not with a fixed client bean, unless there's some kind of injectable cookie store to use that's per-conversation. That's going to be very difficult to get right. You might end up having to plug in response processing code that pulls off the cookies yourself.

>    Hmm. I don't think it is multiple integrations in the way you are 
>    thinking; basically it is intended in this scenario that the user gets 
>    to choose what authentication policy they want to satisfy.

In most cases, users don't set policy, the org does, and the user just lives with it. There may be choices within that, but not at the level of literally deciding whether a policy affects them. And in turn most orgs have many different policies for different services. One size definitely doesn't fit all most of the time.

>    You need a subflow for views?

No, but it will get messy to try to combine all of this into a single flow, I would expect you might end up with subflows for the different methods, and for selecting them in the first place, just to keep things organized.

>    The difference here is that duo made their UI with the intention of it 
>    being incorporated into other products cleanly. The rapid identity web 
>    UI is more designed for just being used directly as its own product.

That's Duo now, it's called the Universal Prompt. Same thing. Yes, I think it's ugly, but that's them not providing sufficient customization, not a problem with the concept as a whole.

>   To  use their UI with the idp would most likely require using the SAML 
>    proxy. That would probably be easier to get working than developing this 
>    module using their web API, but it wouldn't be as clean of an 
>    integration as you would clearly be jumping from the idp UI to the RI UI.

Yes, and that's how they all work now. It's just the way it is. Fighting that wave is more or less pointless.

-- Scott