Duo Security Authentication and IdPv3

[Cantor, Scott]

On 4/29/15, 7:05 PM, "Jonathan Johnson" <jsjohnson at unicon.net> wrote:


>
>3. Only the second authen context is being reported back to the SP. Not 
>such a big deal right now, but something I will have to come back to 
>later.

SAML only allows for a single context class in a response, there will only 
ever be one. The one that comes back is whatever AuthenticationResult was 
used to satisfy the request when the "real" authentication flow runs. The 
initial authentication sequence may or may not produce the result that 
satisfies the request, just depends on the situation.

>Given these, would it be better, then, to just write a single auth 
>handler that has a tighter loop and handles these step ups?

Nothing you mentioned would factor into that decision that I can see. None 
of that is "bad", and in fact it would be very bad if it didn't operate 
that way.

The only real comments I have are:

- Locally combining SFA methods to produce a pseudo-MFA method is much 
more complex than true MFA, as I keep saying.

- I can easily believe that a single flow handling both will be simpler to 
understand and manipulate than relying on multiple flows, but my only 
concern would be that this shouldn't be any harder than trying to do the 
same thing with the MCB now. If it's harder, then something probably needs 
to be cleaned up, as long as it's not just a question of documentation.

The main reason it's a hassle to do the password step all over again is 
that it's potentially a lot of duplication of settings, but even that's 
not entirely certain. You could possibly manage to to run the password 
step by embedding a call to that flow inside a custom login flow, and 
reuse most of it.

> I can sort of mitigate what’s going on right now with just the one step 
>up, but if I get to where I need another (say, adding a biometric to the 
>mix), I might need a little bit more than is available currently.

I don't really follow what you're trying to mitigate, but we can talk 
about it.

>            <param-value>${idp.home}/system/conf/mvc-beans.xml 
>${idp.home}/system/conf/webflow-config.xml 
>classpath*:/META-INF/shib/conf/webflow-config.xml</param-value>

I think adding a separate webflow-config would be risky, but never having 
tried it I don't know. In particular, you may not have exercised certain 
interrelationships that exist between the flows (parent flows and such) 
and it may not work once certain cases are tested.

>Allowing spring to pull from the classpath has allowed me to have a drop 
>in jar that contains all the configuration needed for the authentication 
>handler and flows without having a lot of other configuration to do in 
>the system itself.

I'm not sure I believe absent evidence that it would locate and load all 
the possible files in multiple jars doing that. If it did, then I think 
defining a convention for that would be very useful.

>It was suggested that I might join the dev call some week to go over some 
>of this with you all, perhaps to go over some of this.

We want to get dedicated agenda items set ahead of time, but otherwise the 
calls are always open.

Thanks,
-- Scott