idp auth module plugin

[Paul Henson]

On 7/20/2022 5:30 AM, Cantor, Scott via dev wrote:

> The problem with that is you can't implement policies that vary by
> service and that's pretty much a day 2 requirement, if not day 1.

Hmm, with the Duo stuff you can have multiple different integrations 
with different settings and as you said on the idp you can have 
arbitrary policy deciding which one to use for a given authentication. I 
don't think you can do that with rapid Identity, the authentication API 
only takes into account the username and the source IP address.

> fact, you might even immediately get asked to fill the gap, by
> imposing policy locally on the methods allowed for the user based on
> the service or other criteria, i.e. what ever other vendor I think

Yes, instead of letting the user choose arbitrarily between whatever 
authentication policies apply to them, the idp could arbitrate that 
based on specific criteria of the current authentication attempt.

> provides themselves. I guess that might be a value-add, but I would
> wonder if that's something they give you if you use their service
> natively instead of fronting it.

I don't think so. Their authentication policy framework seems to be user 
based, not service based; in their best practices document:

	https://help.rapididentity.com/docs/authentication-policies-best-practices

it says "Authentication methods are assigned to users within 
RapidIdentity Identity Store based on user attributes." It seems pretty 
much designed that how a user needs to authenticate is based on the 
user, not on the service.

> Because the normal model is for a singleton HttpClient shared by the
> system, and the lack of synchronization there would break it.

Ah, I was thinking after I sent that email whether or not the cookie 
store would end up getting shared across multiple authentication 
processes and result in cookie contamination 8-/, sounds like it does.

> I would expect though that the cookie management injection point
> would be into the HttpClient "context" used for each call

I think I saw a reference that, something along the lines of:

HttpClientContext context = HttpClientContext.create();
CookieStore cookieStore = new BasicCookieStore();
context.setCookieStore(cookieStore);

httpClient.execute(request, httpClientContext);


So I should be able to create the cookie store at the beginning of the 
flow, persist it in the authentication context, and then have the http 
client use it for each request.

If I understand correctly, the pieces in play would be defining the 
security parameters:

<bean id="rapidHttpSecurity" 
class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticPKIXTrustEngine"
			p:certificates="%{idp.home}/credentials/rapid.pem"
			p:checkNames="false" />
	</property>
</bean>


Setting up an http client to do enhanced TLS:
     <bean id="rapidHttpClient" parent="shibboleth.HttpClientFactory"
 
p:tLSSocketFactory-ref="shibboleth.SecurityEnhancedTLSSocketFactory" />


Instantiate a class that gets passed those two things:

     <bean id="rapidAPICall"
           class="id.signet.idp.plugin.authn.rapid.impl.rapidAPICall"
           c:client-ref="rapidHttpClient"
           c:parameters-ref="rapidHttpSecurity" />


with a constructor accepting them:

     public rapidAPICall(
             @Nonnull final HttpClient client, @Nonnull final 
HttpClientSecurityParameters parameters) {


then in the method that makes the API call, create a client context 
configured with the security parameters and cookie container:

         HttpClientContext clientContext = HttpClientContext.create();
 
HttpClientSecuritySupport.marshalSecurityParameters(clientContext, 
securityParameters, true);
	[get cookieStore from auth context]
	clientContext.setCookieStore(cookieStore);


and finally make a request using the context and confirming the TLS 
verification was successful:

             HttpPost request = new HttpPost(uri);
             response = client.execute(request, clientContext);
 
HttpClientSecuritySupport.checkTLSCredentialEvaluated(clientContext, 
request.getURI().getScheme())

> have a subcontext they use for themselves of course, but the main one
> is there already.

Yah, I meant a subcontext for the rapid authentication. I'm not quite 
clear though, is that primarily intended for persisting things that get 
passed out of the flow for other components to have available, or is it 
also the best place to persist whatever other random internal state is 
necessary within the flow itself for controlling execution between steps?

> Subflows just keep the behavior more organized and modular, and
> sometimes a little easier to understand the flow overall. Same as
> functions in any other procedural language.

Cool, that's what I thought. I will just start with everything at the 
top level initially and take a look at subflows if it seems like it's 
getting too cluttered or complicated.

Thanks much…

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