Shibboleth MFA questions

[Cantor, Scott]

On 5/22/17, 6:53 PM, "users on behalf of s-awinte at haw-landshut.de" <users-bounces at shibboleth.net on behalf of s-awinte at 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