Writing auth processing filter - how do you get the original username?

[greg....@gmail.com]

Hi,

I'm trying to make an auth processing filter, a bit like this one - https://github.com/simplesamlphp/simplesamlphp-module-yubikey - but for LinOTP (because then I can support multiple OTP options, not only YubiKeys) and I have a question to help make user's lives a bit easier. LinOTP needs to be passed a username along with the OTP. We already know the username, because prior to the second factor check LinOTP will carry out there's a standard LDAP login. I don't want to make users enter their username *again* - they did it once already. How do I retrieve the username they entered during the LDAP login to re-use at the LinOTP step, so I don't need to ask for it to be re-entered?

Thanks,

Greg

[Peter Schober]

* greg....@gmail.com <greg....@gmail.com> [2017-09-15 14:32]:

> I'm trying to make an auth processing filter

May I ask why not an authsource? Do you intend to allow logins
re-using the SSO session and only prompting for the second factor
alone? In most other cases I'd always ask for the token together (at
the same time, in the same login UI) as the primary authn factor.
-peter

[greg....@gmail.com]

On Friday, 15 September 2017 14:39:05 UTC+2, Peter Schober wrote:

May I ask why not an authsource? Do you intend to allow logins
re-using the SSO session and only prompting for the second factor
alone?

Exactly this! :-)

I don't want to use LinOTP as a single authsource, I want it to be an additional second factor check, which is how I currently have the YubiKey module working. If the person still has a valid LDAP session open with SimpleSAMLphp it just asks for a token.

[Peter Schober]

* greg....@gmail.com <greg....@gmail.com> [2017-09-15 14:44]:

> I don't want to use LinOTP as a single authsource, I want it to be an
> additional second factor check, which is how I currently have the YubiKey
> module working. If the person still has a valid LDAP session open with
> SimpleSAMLphp it just asks for a token.

Well, have a look at some of the existing authproc filters that
operate on the UserID of the currently logged in subject, e.g.
https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/core/lib/Auth/Process/TargetedID.php
This get's the 'UserID' key from the $state array.

No idea whether that's using the lates APIs and therefore makes a good
basis for new developments. though.
-peter

[greg....@gmail.com]

Though you make a good point, I could consider forking the LDAP core module and adding an 'OTP' field to it... That hadn't really occurred to me, because the "usual" approach to a second factor check is some kind of interstitial behaviour (see LastPass, NextCloud, Google, Linode manager, pretty much anywhere 2FA is done). In fact, I think the only place I've seen the OTP demanded on the same page as username and password is with Gandi.net.

[greg....@gmail.com]

On Friday, 15 September 2017 14:49:40 UTC+2, Peter Schober wrote:

Well, have a look at some of the existing authproc filters that
operate on the UserID of the currently logged in subject, e.g.
https://github.com/simplesamlphp/simplesamlphp/blob/master/modules/core/lib/Auth/Process/TargetedID.php
This get's the 'UserID' key from the $state array.

No idea whether that's using the lates APIs and therefore makes a good
basis for new developments. though.
-peter

Ahh, so it might be there already in $state. Brilliant, thanks Peter. I'll take a look.

[Peter Schober]

* greg....@gmail.com <greg....@gmail.com> [2017-09-15 14:52]:

I guess it comes down to the desired behaviour. Arguably SSO session +
OTP is still "better" than only the SSO session, but terminologically
speaking I think the OTP is considered a second factor only in
combination with the primary authentiacation factor (not an SSO
session), and that's username + passwort auth via LDAP auth in your
case.

Personally I've only used OTPs in strict conjunction with
password-based authentication, i.e., if something asks for higher
authn assurance they get it by subjects having to provide both
factors on the login page, i.e., authenticate with username, passwort
*and* OTP.

If that's all in one module (authsource) it should be easier and more
secure to guarantee that all it happens (by ensuring it happens in the
same step), rather than relying on other mechanisms (authproc filters
here) to tie them together in a more lose sense.

Just my 2ข.
-peter

[Jaime Perez Crespo]

Hi Greg,

You have both options: integrating 2FA as part of the old login flow, everything in the same form and in the same module, or having an additional module that deals only with 2FA in a separate page. The latter has several advantages, as it’s simpler to implement (you only need to implement the second factor, not the “first" authentication), does not require the modification of any existing page layouts (i.e. the login form) and is more flexible, as if you later want to add several 2FA methods to choose from, then it’ll be easier to do.

Personally, I’d go for the latter. In Feide we did a mix. We have our own module that deals with authentication, including the second factor as part of the authentication source. However, the second factor is authenticated in a separate form after username/password authentication, as we allow the user to choose from a list of 2FA methods, and that list depends on what the user has configured (and his organization allowed).

Regarding the technical details, that might be a bit more for the development mailing list. In any case, authproc filters (and auth sources, for that matter) will always have access to the state array. There you’ll have, among many other things, an array with the attributes of the user under the “Attributes” key (provided the user was already authenticated, of course). Use that and make it configurable so that you can define which attribute you want to use to univocally identity the user. Don’t rely on the “UserID” in the state array, as that will go away in future versions of SSP.

--
Jaime Pérez
UNINETT / Feide

jaime...@uninett.no
jaime...@protonmail.com
9A08 EA20 E062 70B4 616B 43E3 562A FE3A 6293 62C2

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost

[Greg Harvey]

There's a development mailing list? Good to know! I think I'll need it. Decided to go for the latter, actually copying your Yubikey module, Jaime. :-)

But I'm getting a really weird thing, the process() method in the filter doesn't seem to get called. Can't figure out why. Consequence is the config doesn't get saved to state, so I can't access it where I need it in the authenticate() method. :-(

Cheers,

Greg

--
This is a mailing list for users of SimpleSAMLphp, not a support service. If you are willing to buy commercial support, please take a look here:

https://simplesamlphp.org/support

Before sending your question, make sure it is related to SimpleSAMLphp, and not your web server's configuration or any other third-party software. This mailing list cannot help with software that uses SimpleSAMLphp, only regarding SimpleSAMLphp itself.

Make sure to read the documentation:

https://simplesamlphp.org/docs/stable/

If you have an issue with SimpleSAMLphp that you cannot resolve and reading the documentation doesn't help, you are more than welcome to ask here for help. Subscribe to the list and send an email with your question. However, you will be expected to comply with some minimum, common sense standards in your questions. Please read this carefully:

http://catb.org/~esr/faqs/smart-questions.html
---
You received this message because you are subscribed to a topic in the Google Groups "SimpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/ocQols0NCZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlphp+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Harvey]

Well, I'm happy to say I think my problems were just opcode caching. I went away for a couple of hours and tried viewing the same config array again when I got back... and it worked. It's worked ever since. So yeh, something cachy in PHP, I think.

Anyway, for anyone who is interested, I have a fork of the LinOTP module here, with an authproc filter based on Jaime's YubiKey authproc filter added to it:

https://github.com/codeenigma/linotp-auth-simplesamlphp

The only snag is it's not ready for latest stable SimpleSAMLphp, as I'm using the Debian repo version for now. But I intend to make a branch for the latest version of SimpleSAMLphp as well.

Thanks everyone for your help! It seems to be working well now. :-)

Cheers,

Greg

[Jaime Perez Crespo]

Hi Greg,

It’s good to hear that you got it working. It would be great too if you could make it work with latest stable (1.14.x), and in that case, make it also installable with composer so that people can depend on it easily without need to copy manually your module into the modules directory. Just let us know (probably better through the dev mailing list) if you need help to do that.

On 4 Oct 2017, at 19:19 PM, Greg Harvey <greg....@gmail.com> wrote:
> Well, I'm happy to say I think my problems were just opcode caching. I went away for a couple of hours and tried viewing the same config array again when I got back... and it worked. It's worked ever since. So yeh, something cachy in PHP, I think.
>
> Anyway, for anyone who is interested, I have a fork of the LinOTP module here, with an authproc filter based on Jaime's YubiKey authproc filter added to it:
> https://github.com/codeenigma/linotp-auth-simplesamlphp
>
> The only snag is it's not ready for latest stable SimpleSAMLphp, as I'm using the Debian repo version for now. But I intend to make a branch for the latest version of SimpleSAMLphp as well.
>
> Thanks everyone for your help! It seems to be working well now. :-)