Creating user for REMOTE_USER authentication in apache.rb

Development
#1

Hello,

the code in app/services/sso/apache.rb allows authentication of a user
based on some Apache module (mod_auth_*). The code in
app/services/sso/basic.rb calls User.try_to_login which in case the
user is not found in the database yet via find_by_login, cycles the
auth sources and tries to find the user there, authenticate, and then
creates the user with the appropriate AuthSource set.

I wonder what the expected behaviour should be for situations when
authorize_login_delegation is set and some Apache module authenticates
the user but the user hasn't been precreated in the database.
Currently the authentication fails.

Before preparing patch draft, I'd like to make sure I'm putting the
logic into the correct place. It seems like we'd need variant of
try_to_auto_create_user which would not require password (the user
has already been authenticated, possibly without a password in case
of for example GSSAPI) and would create the user.

For users authenticated via authorize_login_delegation, should they
be created with AuthSourceInternal or should I create something like
AuthSourceExternal? Also, should the auto-creation feature have yet
another configuration option in settings.yaml?

Of course, the authentication module would need to pass in the
attributes needed for the User object but my hope is that
module similar to

https://github.com/adelton/mod_lookup_identity

could help.

Thank you for any hints about the preferred place for the new logic to
live in.

··· -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat
#2

Hello,

see my answers below in your text

> Hello,
>
> the code in app/services/sso/apache.rb allows authentication of a user
> based on some Apache module (mod_auth_*). The code in
> app/services/sso/basic.rb calls User.try_to_login which in case the
> user is not found in the database yet via find_by_login, cycles the
> auth sources and tries to find the user there, authenticate, and then
> creates the user with the appropriate AuthSource set.
>
> I wonder what the expected behaviour should be for situations when
> authorize_login_delegation is set and some Apache module authenticates
> the user but the user hasn't been precreated in the database.
> Currently the authentication fails.

For the user I think it would be best to create new user on the fly and force
him to enter other info we need (e.g. mail address). As Ohad correctly
suggested on IRC, we don't want to create users into internal DB since it's
apparent that he is stored somewhere else.

I think it would be nice if we could link various authentication methods with
AuthSources in which they should be created. You would then implement
AuthSource for you user DB and set a link (ideally using foreman settings).

This is just suggestion, someone may have better idea how to detect the right
AuthSource.

> Before preparing patch draft, I'd like to make sure I'm putting the
> logic into the correct place. It seems like we'd need variant of
> try_to_auto_create_user which would not require password (the user
> has already been authenticated, possibly without a password in case
> of for example GSSAPI) and would create the user.

I'm not sure what exactly you're trying to achieve but I think what you need
is to add a new SSO method under app/services/sso/. See existing ones for some
examples.

Also note that preferred way of adding new methods is via plugins. You can
read something about it here [1]

And a small warning, the whole authentication part will change somehow in a
near future. We may even use warden or something like that.

> For users authenticated via authorize_login_delegation, should they
> be created with AuthSourceInternal or should I create something like
> AuthSourceExternal? Also, should the auto-creation feature have yet
> another configuration option in settings.yaml?
>
> Of course, the authentication module would need to pass in the
> attributes needed for the User object but my hope is that
> module similar to
>
> https://github.com/adelton/mod_lookup_identity
>
> could help.
>
> Thank you for any hints about the preferred place for the new logic to
> live in.

[1] Plugins - Foreman

··· On Thursday 10 of October 2013 13:42:54 Jan Pazdziora wrote:

–
Marek

#3

> >
> > I wonder what the expected behaviour should be for situations when
> > authorize_login_delegation is set and some Apache module authenticates
> > the user but the user hasn't been precreated in the database.
> > Currently the authentication fails.
>
> For the user I think it would be best to create new user on the fly and force
> him to enter other info we need (e.g. mail address). As Ohad correctly
> suggested on IRC, we don't want to create users into internal DB since it's
> apparent that he is stored somewhere else.

I'm afraid I don't have a record of that communication. Do you say you
do not want the user stored in the database at all and ask the user
for their email address every time they log in, or that you do not
want the user stored with AuthSourceInternal?

> I think it would be nice if we could link various authentication methods with
> AuthSources in which they should be created. You would then implement
> AuthSource for you user DB and set a link (ideally using foreman settings).

Please note that there is no "user DB", really. There is an
authentication which happens outside of the Foreman application,
signalled by REMOTE_USER being set. What Apache module did that
authentication and based on what credentials or decision the
application has to way of knowing and figuring out, unless the
mod_auth_* modules pass that information together with REMOTE_USER,
or the information is configured in static way on Foreman side.
Which is certainly doable – we can introduce
authorize_login_delegation_user_autocreate_auth_source value which
will be used to lookup the correct AuthSource.

> > Before preparing patch draft, I'd like to make sure I'm putting the
> > logic into the correct place. It seems like we'd need variant of
> > try_to_auto_create_user which would not require password (the user
> > has already been authenticated, possibly without a password in case
> > of for example GSSAPI) and would create the user.
>
> I'm not sure what exactly you're trying to achieve but I think what you need

I'm trying to be able to authenticate using mod_auth_*, via the
REMOTE_USER mechanism. Currently, the authentication fails on the
application level – Foreman wants to be able to find the user in
the database. So I'm trying to put the user record to exactly the
place where existing Foreman code will then be able to find it.

> is to add a new SSO method under app/services/sso/. See existing ones for some
> examples.

But app/services/sso/apache.rb is already there and for users that
already exist in the database, it does the right thing. How would that
new method differ from apache.rb?

··· On Thu, Oct 10, 2013 at 02:26:14PM +0200, Marek Hulan wrote:

–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat

#4

Marek,

the pull request

https://github.com/theforeman/foreman/pull/986

now builds on the previous work and makes it possible to actually
populate the email address (and other attributes of the user) from the
environment variables, making it possible for the external
authentication module to provide the data.

I've now amended the description of

http://projects.theforeman.org/issues/3528

with instructions for setting mod_lookup_identity and sssd-dbus to
make use of that patch.

Could you please check the instructions and add/amend the tests for
the pull request (since we change a little bit the things done in
https://github.com/theforeman/foreman/pull/967?

Thank you,

··· On Thu, Oct 10, 2013 at 02:26:14PM +0200, Marek Hulan wrote: > > For the user I think it would be best to create new user on the fly and force > him to enter other info we need (e.g. mail address). As Ohad correctly

–
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat

#5

> > > I wonder what the expected behaviour should be for situations when
> > > authorize_login_delegation is set and some Apache module authenticates
> > > the user but the user hasn't been precreated in the database.
> > > Currently the authentication fails.
> >
> > For the user I think it would be best to create new user on the fly and
> > force him to enter other info we need (e.g. mail address). As Ohad
> > correctly suggested on IRC, we don't want to create users into internal
> > DB since it's apparent that he is stored somewhere else.
>
> I'm afraid I don't have a record of that communication. Do you say you
> do not want the user stored in the database at all and ask the user
> for their email address every time they log in, or that you do not
> want the user stored with AuthSourceInternal?

Sorry for confusion, the second is right. We don't want to store him with
AuthSourceInternal since it's obvious he is from some external source.

> > I think it would be nice if we could link various authentication methods
> > with AuthSources in which they should be created. You would then
> > implement AuthSource for you user DB and set a link (ideally using
> > foreman settings).
> Please note that there is no "user DB", really. There is an
> authentication which happens outside of the Foreman application,
> signalled by REMOTE_USER being set. What Apache module did that
> authentication and based on what credentials or decision the
> application has to way of knowing and figuring out, unless the
> mod_auth_* modules pass that information together with REMOTE_USER,
> or the information is configured in static way on Foreman side.
> Which is certainly doable – we can introduce
> authorize_login_delegation_user_autocreate_auth_source value which
> will be used to lookup the correct AuthSource.

Sounds good.

> > > Before preparing patch draft, I'd like to make sure I'm putting the
> > > logic into the correct place. It seems like we'd need variant of
> > > try_to_auto_create_user which would not require password (the user
> > > has already been authenticated, possibly without a password in case
> > > of for example GSSAPI) and would create the user.
> >
> > I'm not sure what exactly you're trying to achieve but I think what you
> > need
> I'm trying to be able to authenticate using mod_auth_*, via the
> REMOTE_USER mechanism. Currently, the authentication fails on the
> application level – Foreman wants to be able to find the user in
> the database. So I'm trying to put the user record to exactly the
> place where existing Foreman code will then be able to find it.
>
> > is to add a new SSO method under app/services/sso/. See existing ones for
> > some examples.
>
> But app/services/sso/apache.rb is already there and for users that
> already exist in the database, it does the right thing. How would that
> new method differ from apache.rb?

Ok so I guess that the way would be:

  1. add new auth source that will be used by Apache (app/models/auth_sources)
  2. provide info by apache module so auth source lookup is possible
  3. extend app/services/sso/apache.rb to use it
  4. convert it to a plugin

Does it make sense?

··· On Monday 14 of October 2013 09:13:25 Jan Pazdziora wrote: > On Thu, Oct 10, 2013 at 02:26:14PM +0200, Marek Hulan wrote:

–
Marek

#6

> >
> > But app/services/sso/apache.rb is already there and for users that
> > already exist in the database, it does the right thing. How would that
> > new method differ from apache.rb?
>
> Ok so I guess that the way would be:
> 1) add new auth source that will be used by Apache (app/models/auth_sources)

Added as

https://github.com/theforeman/foreman/commit/c3167dce2c17225a203f798ace3b57dd44901f5d#diff-0

> 2) provide info by apache module so auth source lookup is possible

Actually, we configure it in settings.yaml:

https://github.com/theforeman/foreman/commit/c3167dce2c17225a203f798ace3b57dd44901f5d#diff-1

> 3) extend app/services/sso/apache.rb to use it

Added a call to use the
authorize_login_delegation_auth_source_user_autocreate value:

https://github.com/theforeman/foreman/commit/c3167dce2c17225a203f798ace3b57dd44901f5d#diff-3

> 4) convert it to a plugin

I have no idea why or how so I leave this one to yourself or some
other Foreman core developer.

··· On Mon, Oct 14, 2013 at 08:47:20AM +0200, Marek Hulan wrote:

–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat

#7

I'll look at it today. If I manage to finish tests I'll create a PR against
your fork. Thanks for new patch!

··· -- Marek

On Thursday 12 of December 2013 14:45:09 Jan Pazdziora wrote:

On Thu, Oct 10, 2013 at 02:26:14PM +0200, Marek Hulan wrote:

For the user I think it would be best to create new user on the fly and
force him to enter other info we need (e.g. mail address). As Ohad
correctly
Marek,

the pull request

https://github.com/theforeman/foreman/pull/986

now builds on the previous work and makes it possible to actually
populate the email address (and other attributes of the user) from the
environment variables, making it possible for the external
authentication module to provide the data.

I’ve now amended the description of

Feature #3528: When new users are created based on REMOTE_USER authentication, their attributes should be populated as well - Foreman

with instructions for setting mod_lookup_identity and sssd-dbus to
make use of that patch.

Could you please check the instructions and add/amend the tests for
the pull request (since we change a little bit the things done in
https://github.com/theforeman/foreman/pull/967?

Thank you,

–
Marek