idp auth module plugin

[Paul Henson]

We are planning to put together an idp authentication module plug-in to 
support using the Rapid Identity authentication API. Rapid Identity is a 
commercial IAM released by Identity Automation:

	https://www.identityautomation.com/


Evidently it is seeing some popularity within the higher education 
community. While it includes its own SAML idp implementation, similar to 
other use cases where identity is maintained in Azure AD or a different 
commercial repository there is a desire to continue to use the 
shibboleth idp as the InCommon facing idp. Bradley University is 
sponsoring the development of the module, their specific use case is for 
it to provide TOTP and push MFA similar to Duo after using a built-in 
idp password authentication flow. They would like to open source the 
module once it is complete, and offer it to the consortium for inclusion 
in the distribution if there is interest. So I come seeking wisdom to 
make sure what we build will meet the idp’s strict standards and design 
philosophy :).

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.

While Bradley intends to use it as a secondary authentication flow after 
a password authentication, theoretically it could be a primary 
authentication flow as it supports password authentication, or if 
somebody wanted to use something other than passwords as a primary 
authentication mechanism. So my plan is for the first flow action to 
create the rapid authentication context and check to see if there is 
already a username associated with the request. If so, it will jump 
immediately to an action that initiates the rapid API. If not, it will 
jump to a form for a user to fill in the username, then process it and 
attach a username principal for the context, and then move on to the 
rapid API initialization. This initial step will also check for headers 
and store them to control the authentication process in the case of 
passive or non-browser access.

The API is REST-based over HTTPS:

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


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

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.

After the initialization call based on the supplied username the API 
returns either a specific authentication method or a list of policies a 
user can choose from along with what methods are included in them. If a 
specific authentication method is returned the flow will jump directly 
to processing it if whatever input necessary has already been supplied 
(eg, a TOTP code via a header) or if no input is necessary (eg, a push 
authentication). If input is required, it will jump to a view state 
displaying a form asking for the necessary input which will then be 
processed.

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.

If a specific authentication method succeeds, the API either returns 
that the authentication is complete, or it returns the next 
authentication method a user must pass. The flow will bounce between the 
necessary forms and authentication processing states until it reaches 
completion and moves on or an error is reached and the flow is aborted.

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…


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