idp auth module plugin

[Paul Henson]

On 7/19/2022 5:15 AM, Cantor, Scott via dev wrote:

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

I'm pretty sure the only input from the client side for their 
authentication API is the username and what IP address the request is 

coming from:

	https://ri-doc-lts-html5.identitymgmt.net/en/initialization.html


Every other decision involved is based on configuration on the server side:

	https://ri-doc-lts-html5.identitymgmt.net/en/authentication.html

> That's much trickier. We've never done it, the state challenges are
> very big.

Always a big confidence builder when you think some task involving the 
IDP is tricky ;).

> I don't know how that would or could be done.

I'm sure I'm missing something as to why this is more complicated or 
difficult within the Spring framework, but why couldn't I just create a 
new cookie store:

	CookieStore cookieStore = new BasicCookieStore();

persist it in the authentication context, and tell the client to use it 
before I make each call?

	httpClient.setCookieStore(cookieStore);

> difficult to get right. You might end up having to plug in response
> processing code that pulls off the cookies yourself.

It looks like it only uses two cookies, 'JSESSIONID', and 'fas', they 

are set during the initialization call and remain the same throughout 

the course of the authentication session, so if necessary I could manage 
them manually without too much effort.

> In most cases, users don't set policy, the org does, and the user
> just lives with it.

Right, but in this case, the policy that the organization has set is 
that the user gets to choose between different MFA methods. This is no 
different than when using duo you can use either SMS, OTP, push, or 
voice, depending on the policy set by the organization. It's just 
implementation details and terminology, and in the rapid identity 
framework, you create multiple authentication policies, one for each 
possible MFA option, and then the user gets to choose which one to satisfy.

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

Hmm. I hacked together a quick flow diagram, it does look messy, but I 
think that's more because I suck as a graphic artist than the flow is 

too complicated 8-/. I'm not sure if the attachment will go through.

But basically it starts off initializing the flow, creating the 
authentication context, checking for options and property/headers or 
cookies, and then checking if there is already a username associated 
with the request.

If there is a username, it jumps directly to initializing the rapid API. 
Otherwise, it displays a username form and then processes it, and then 
goes to the rapid API initialization.

The rapid API initialization determines what authorization mechanisms 

the user needs to do, and whether it has enough information to directly 
jump to processing one of them, or if it needs to display a form. It 
will either immediately jump to processing password, TOTP, or 
Ping(push), display a form asking for the password or TOTP code, or 
display the authentication selection form if the user needs to pick what 
to do.

The authentication selection form will then either go to the TOTP form, 
password form, or immediately to ping auth.

The authentication processing will either succeed and continue on back 
to the idp, or fail and give an error or allow the option to try again.

I'm not sure how using subflows for it would work, as from the top level 
flow you might jump to the password form or to the password processing, 
or to the TOTP form or directly to processing. It would depend on 
whether or not the user sent the necessary authentication information in 
headers for non-browser authentication.

Dunno. I'm sure I'm missing something that will make things more 
complicated than I think they will be.

> That's Duo now, it's called the Universal Prompt.

Ah, we haven't switched to that yet, and I haven't paid much attention 
to it.

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

Yup. But it's what they want, so if I can make it work, I'm going to try 
and make it work.


Thanks for the help…

-- 
Signet - The Art of Access
https://www.signet.id/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rapidapi-flow.pdf
Type: application/pdf
Size: 14668 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/dev/attachments/20220720/ac2ba330/attachment-0001.pdf>