[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: Custom AuthN Flow
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2017-01-25 18:31:23
Message-ID: BCB10D11-1F39-43AF-9236-06BE6E2D56B3 () osu ! edu
[Download RAW message or body]

On 1/25/17, 11:57 AM, "users on behalf of Albert Zaharovits" \
<users-bounces@shibboleth.net on behalf of azaharovits@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


-- 
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net


[prev in list] [next in list] [prev in thread] [next in thread]