Custom AuthN Flow

[Cantor, Scott]

On 1/25/17, 11:57 AM, "users on behalf of Albert Zaharovits" <users-bounces at shibboleth.net on behalf of azaharovits at veridiumid.com> wrote:

> Note that compared to the duo second factor implementation the Subject is not filled by a previous authn flow it is filled
> together with the AuthenticationResult by this flow, as the mobile app is registered to a Subject on the external server.

That isn't really different from Duo in any material way. They're both flows that do something specific and produce a specific result. The only unusual thing about the Duo flow is that it happens to bootstrap itself with a username it picks up with a function that normally gets it from a previous flow. That just happens to be a requirement for Duo to work.

What is *not* specific in the Duo flow is any assumption about where that name comes from or that any other authentication mechanism was used. That comes out of how it's deployed by means of the MFA flow and the rules that are created for it. That is the lesson: build your flow and do what it needs to do and nothing more or less. If you do that, then people can deploy it in whatever way they need to without any impact on your code and it all hangs together cleanly.

One hint that's emerged from other people's work is that you generally want to create a technology-specific custom Principal type to capture basic information about the login. For example, the name of the subject, which I put into a DuoPrincipal in the case of that flow. Don't use UsernamePrincipal for technologies that are not password-based or likely to be used in addition to a password. It creates conflicts later when the system merges things together that make using the system's other features more complicated.

> What do you think about that?

I don't have any particular comment pro or con on what you're suggesting, and there are no details given that would allow for a real security analysis, even if I were inclined to spend my time doing one. Not that I'm any sort of expert anyway.
    
> I must admit I am stumped and I think I need  some help from the developers on that.

This isn't the list for that, but I can't help much anyway. All I have is what is already there, the code and the minimal documentation I put together on writing login flows, it's in the wiki on the Design/Development side. I am aware it's insufficient, but it will remain that way as long as I'm the one who has to do it and my time is otherwise allocated. If something specific is identified that should be captured, I can do quick additions where necessary.

-- Scott