idp auth module plugin

[Cantor, Scott]

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

>    I’m planning to base it on the existing TOTP example authentication 
>    module; I am reasonably familiar with Java but spring and XML have been 
 >   known to make my head hurt ;). I doubt if I could put this together from 
>    a blank slate but between the example module and other idp source code 
>    to reference I think it should work out.

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. A third party extension, of which there haven't been any, would not use those classes, but could/should use the ones in the API that implement the right machinery on top of property files (you just have to supply some of the properties we default in).

net.shibboleth.idp.module.PropertyDrivenIdPModule
net.shibboleth.idp.plugin.PropertyDrivenIdPPlugin

>    The rapid identity product can either be run on premise or it has a 
>    hosted cloud service. The URL to access it will be a property.

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.

> There are no keys or shared secrets between the server and the client, the client 
>    trusts the server based solely on the SSL certificate it presents. As 
>    such, from a design perspective, would it be preferred to require that 
>    the certificate to validate the server be explicitly configured like 
>    with the LDAP client as opposed to using the default built in Java CA 
>    certificate store?

Nothing we support is allowed to rely on the default store anymore, not even as an option. We do not have a problem with settings that disable trust, and that's simply the explicit version of using the root store, which is full of garbage.

>    Rapid identity supports a fairly flexible authentication policy 
>    mechanism. An authentication policy defines which authentication methods 
>    and in which order they must be done to successfully authenticate. It is 
>    also possible that multiple authentication policies might apply to a 
>    user and allow them to choose which one they would like to use.

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. That's a bit harder to accommodate since it means you have to wrap the selection process in a subflow to support views.

>    If a list of policies is returned, in the base case that each policy 
>    only has one authentication method (eg, you can pick between TOTP or 
>    push) a simple form will be displayed allowing the selection of the 
>    desired authentication method. If the policies have more than one 
>    authentication method, a more complicated form will be displayed naming 
>    the specific policies and showing which authentication methods they 
>    include allowing a user to choose between them. I’m planning to allow 
>    the user to have the option to save their preference in a cookie so the 
>    next time they need to authenticate they won’t have to choose.

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

>    This is a pretty rough description, but I wanted to reach out early 
>    before I started the detailed implementation to see if anyone had any 
>    concerns or suggestions about this planned project (or perhaps the 
>    unlikely case that someone else was already working on a similar 
>    project). Thanks much for any thoughts or insights…

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.

-- Scott