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

List:       shibboleth-users
Subject:    Re: Shibboleth MFA questions
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2017-05-23 0:24:37
Message-ID: C6AB22BE-E95F-4A19-B045-22F032C29D5C () osu ! edu
[Download RAW message or body]

On 5/22/17, 6:53 PM, "users on behalf of s-awinte@haw-landshut.de" \
<users-bounces@shibboleth.net on behalf of s-awinte@haw-landshut.de> wrote:

> Well, I assumed that building a user principal name (or canonicalized
> subject, if you will) would be done via reading client cert attributes
> handed over from Apache via:

If you're going to determine the identity from fields extracted from a certificate, \
that is not actually the X509 login flow, that would be RemoteUser (it can pull the \
identity from a header/variable, not just REMOTE_USER). The X509 flow is used when \
you want to consume the certificate itself. While I suppose there might be a need to \
support pulling the certificate in but also reading the identity from a separate \
location, that isn't supported by the X509 flow as it stands now. I don't think the \
documentation is particularly clear on that distinction as it's a bit subtle.

Having said that, if the identity can be determined from the certificate or from what \
Apache pulls out, either way you should have a notionally simple use of one of those \
features. With RemoteUser, the username should just come directly in or after a \
simple transform. That's done via conf/c14n/simple-subject-c14n-config.xml

With X509, you would need to configure the x500 canonicalization step to extract the \
username from the desired piece of the certificate via x500-subject-c14n-config.xml

Both of those have reference documentation in the wiki explaining what the options \
are for. If you wanted an example of how they work in isolation, then you would have \
to propose a scenario you can't figure out and then I could throw one together.

Once that's done, the MFA flow would be able to invoke the desired first factor and \
then pass control to the U2F flow, and that's illustrated in the examples in the \
wiki. Since I don't know what your desired business logic is, I don't know what else \
to outline. I don't know under what conditions you want the U2F flow to run. If you \
want it to run in every case, that's fine, but that's almost *never* what people \
want, so I'm not just going to assume that.

Having never seen anybody ask for X.509 + anything as a single login operation, I'm \
not going to presume I understand what you're doing here. X.509 almost always stands \
alone. Adding a PIN-less token to it seems strange, so I have to assume I really \
don't understand your use case yet, and thus I await enlightenment.

> Probably via a c14n flow, as mentioned by Stefan, or maybe by
> configuring the MFA-flow with the right bean, as in the DUO-flow - but
> which, and how?

Until I know what you're going to do, I'm not going to just list a dozen links into \
the wiki, all or none of which may be unrelated to what you want to actually do. All \
or none of the bits I've mentioned may be involved, though it's a safe bet the MFA \
flow will be.

> https://wiki.shibboleth.net/confluence/display/IDP30/ScriptTypeConfiguration?src=contextnavpagetreemode
>                 
> - quite frugal for a scripting guide.

That has nothing to do with this, and it also explicitly mentions it's a V3.4 \
addition.

Just because I threw the word "scripting" into the conversation doesn't mean you'll \
get anywhere searching for that in the wiki, you'll get almost entirely unrelated \
material.  
> I wonder where I can find information on how your stuff works, apart
> from looking up the source code or dev documentation?

I think the wiki describes how a lot of it works. I can't help that you don't, but \
there's no obvious fix for that.

> https://wiki.shibboleth.net/confluence/display/IDP30/SubjectCanonicalization
> Where can I find a complete overview, e. g. of what beans and scripting
> params to use in which situations - an how?

https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationConfiguration, \
Post-Login Canonicalization, which links to the documentation for the three built-in \
ways of "completing" the use of a login flow/factor. You need to get from a Java \
Subject to a username. For many use cases that's a trivial step (and the "simple" \
flow is used).

For a certificate (which as I said above is for all I know not all what you really \
need), there's a dedicated feature for that. And there's another for doing mapping on \
the fly via LDAP or a database. And worst case there's extending the system, but \
that's much more complex and I very much doubt would be needed.

> I would really support the idea of stocking and dating up the code
> examples on the Sibboleth wiki.
> Good documentation and example resources is what makes people deciding
> for or against a technology.

Unless you have money to put into the budget or some insight into which maintenance \
task we should stop doing instead, it's largely an academic discussion, it will \
continue to evolve at a very slow and minimal pace in the spare time of the \
developers. The wiki is also editable by anybody who cares to contribute their own \
examples. 

Let me close by saying I think you vastly understate the advanced nature of your \
goals here. You are in the 99th percentile of use cases here. The IdP can *do* just \
about anything, but we certainly don't have time to document all the things people \
can do with it ahead of time. The priority is to flesh out obscure material when \
there's a need.

-- 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]