idp auth module plugin

[Paul Henson]

On 7/18/2022 1:58 PM, Cantor, Scott via dev wrote:

> The difference between that plugin and a third party plugin is that 
> our plugins and modules inherit from implementation classes for 
> "first party" extensions that bake in a lot of defaults.

Ah, ok.

> net.shibboleth.idp.module.PropertyDrivenIdPModule

It looks like the only difference between this one and the
PluginIdPModule is that the latter defines a MODULE_URL_BASE that gets
added to documentation.

> net.shibboleth.idp.plugin.PropertyDrivenIdPPlugin

Then the FirstPartyIdPPlugin appears to modify the getDefaultUpdateURLs
method to return the official locations.

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

> You're almost certainly going to immediately have to generalize that
>  to "RapidWhateverIntegration" as with Duo, to allow more than one 
> with different rules, and a function hook that returns the one to 
> use.

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.
There is nothing else as far as I can tell defining the relationship
between a client and a server other than the URL. It's not like duo
where you can have multiple clients of the same API that behave
differently; each user you try to authenticate might be treated
differently, but the actual connection between the IDP and the rapid
identity server will be the same for each one.

> Nothing we support is allowed to rely on the default store anymore, 
> not even as an option.

Yeah, that's what I thought. So I should define a custom httpClient to
validate based on a static certificate like the CAS proxy mechanism does
in cas-protocol-system.xml for the proxyHttpClient/proxyHttpSecurity
beans? Although that pulls the certificate data from the XML
configuration rather than a standalone file in the file system which
would probably be simpler for configuration purposes. 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 basically the generalization of my point above about there 
> being multiple integrations, though with Duo we've never considered 
> allowing the user to be involved in selecting it.

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. For example, 
the configuration Bradley plans to use will have two authentication 
policies, one specifying TOTP, the other push (or pingMe in rapid 
identity terminology). To successfully authenticate against the API, the 
user can choose to either submit a TOTP code, or respond to a push 
authentication on their mobile device. This is basically the same as a 
single duo integration which allows you to choose which authentication 
method you want to use.

I could be missing something though, I can usually understand the 
abstractions and generalizations in the idp, but I don't know that my 
brain would have come up with them on its own...

> That's a bit harder to accommodate since it means you have to wrap
> the selection process in a subflow to support views.

You need a subflow for views? The TOTP module has a view state and there 
aren't any subflows? I thought subflows were more like functions 
allowing you to consolidate and reuse functionality but not strictly 
necessary if you wanted to splatter it all at the top :), but I'm 
definitely not a webflow expert.

> That's a lot of long term work to maintain, particularly because it 
> has to be accessible in the US, etc.

It's a long description, but I don't know that they will be that 
complicated of forms. The TOTP form will be almost identical to the one 
in your TOTP plug-in, it just needs a code entered. The push/pingMe view 
will basically just say "sent a push to your device, waiting for 
response, click here to cancel".

The case where each policy contains only a single authentication method 
might look something like this:

Please choose an authentication mechanism:
     [ ] totp - Code: _______
     [ ] ping
     Submit

Whereas the one with more complicated policies might look like:

Please choose an authentication policy:
     [ ] Easy access - method(s): qrCode
     [ ] Super Secure Access - method(s): webAuthn,pictograph,pingme,totp

> Obviously people have to decide for themselves what they're willing 
> to do, but the general thrust of this makes me concerned that this is
> a pretty large amount of UI work amounting to what a few people did
> with Duo back in the day, and there was a pretty universal sense by
> all the people who did that that it was a bad idea to try and replace
> the vendor's UI.

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

Dunno, they evaluated the proxy option and decided they'd rather have 
this. If it blows up on me maybe they will change their mind :). I've 
got it pretty much done in my head at a design level, the hard part is 
going to be turning that into the specific java/spring/webflow 
implementation details in the context of the idp, I don't have this 
particular technology memorized as well as you guys ;).

Thanks for the comments…

-- 
Signet - The Art of Access
https://www.signet.id/