is getting close to being acceptable as a solution for
http://projects.theforeman.org/issues/3312
The REMOTE_USER authencation will be possible and users will be
populated in Foreman database. However, the user records will only
contain the login – no name, and no email address, so immediatelly
after the login, user will be asked to fill their email address.
I've now filed issue
http://projects.theforeman.org/issues/3528
to address this shortcoming – if the external authentication (or
identity lookup) module populates not just REMOTE_USER but also other
REMOTE_USER_* variables, Foreman will be able to use them to create
the user records to match the external identity source – see the last
commit of
https://github.com/theforeman/foreman/pull/986
The data flow is fairly straightforward.
However, handling roles will probably be more complex and I wanted to
gather opinions before proposing a patch.
If Foreman administrator in enterprise setup enabled for example
Kerberos authentication from their IPA/IdM server, with user
autopopulation, chances are they not only want their users to be able
to log in but they also want to manage their users' access rights
(Foreman roles) in that identity server. In IPA, users can be members
of groups, so some mapping of group membership in IPA to roles in
Foreman seems like feasible solution. Does Foreman already have some
mechanism to assign roles based on groups? If not, would that (ability
of Foreman admin to set up group -> roles mapping) be a viable option?
Or should we keep it simple and just do some text mapping – for
example any group prefixed with "Foreman_" would map to the role with
the same name as the rest of the group name?
Any suggestions are appreciated,
···
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
>
> Hello,
>
> the pull request
>
> https://github.com/theforeman/foreman/pull/967
>
> is getting close to being acceptable as a solution for
>
> Feature #3312: Make it possible to use the REMOTE_USER / sso/apache.rb authentication with mod_auth_kerb - Foreman
>
> The REMOTE_USER authencation will be possible and users will be
> populated in Foreman database. However, the user records will only
> contain the login – no name, and no email address, so immediatelly
> after the login, user will be asked to fill their email address.
>
> I've now filed issue
>
> Feature #3528: When new users are created based on REMOTE_USER authentication, their attributes should be populated as well - Foreman
>
> to address this shortcoming – if the external authentication (or
> identity lookup) module populates not just REMOTE_USER but also other
> REMOTE_USER_* variables, Foreman will be able to use them to create
> the user records to match the external identity source – see the last
> commit of
>
> https://github.com/theforeman/foreman/pull/986
>
> The data flow is fairly straightforward.
>
> However, handling roles will probably be more complex and I wanted to
> gather opinions before proposing a patch.
>
> If Foreman administrator in enterprise setup enabled for example
> Kerberos authentication from their IPA/IdM server, with user
> autopopulation, chances are they not only want their users to be able
> to log in but they also want to manage their users' access rights
> (Foreman roles) in that identity server. In IPA, users can be members
> of groups, so some mapping of group membership in IPA to roles in
> Foreman seems like feasible solution. Does Foreman already have some
> mechanism to assign roles based on groups? If not, would that (ability
> of Foreman admin to set up group -> roles mapping) be a viable option?
> Or should we keep it simple and just do some text mapping – for
> example any group prefixed with "Foreman_" would map to the role with
> the same name as the rest of the group name?
We have something similar in Katello and this mapping seems like a solution
for SSO with roles propagation. +1 from my side.
– Ivan
···
----- Original Message -----
Any suggestions are appreciated,
–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
Which approach do you have in mind – some database table mapping
group names to roles, or the text conversion based?
Can you point me to the relevant code in Katello?
Thank you,
···
On Tue, Oct 29, 2013 at 04:04:34AM -0400, Ivan Necas wrote:
>
> > If Foreman administrator in enterprise setup enabled for example
> > Kerberos authentication from their IPA/IdM server, with user
> > autopopulation, chances are they not only want their users to be able
> > to log in but they also want to manage their users' access rights
> > (Foreman roles) in that identity server. In IPA, users can be members
> > of groups, so some mapping of group membership in IPA to roles in
> > Foreman seems like feasible solution. Does Foreman already have some
> > mechanism to assign roles based on groups? If not, would that (ability
> > of Foreman admin to set up group -> roles mapping) be a viable option?
> > Or should we keep it simple and just do some text mapping -- for
> > example any group prefixed with "Foreman_" would map to the role with
> > the same name as the rest of the group name?
>
> We have something similar in Katello and this mapping seems like a solution
> for SSO with roles propagation. +1 from my side.
–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
> >
> > > If Foreman administrator in enterprise setup enabled for example
> > > Kerberos authentication from their IPA/IdM server, with user
> > > autopopulation, chances are they not only want their users to be able
> > > to log in but they also want to manage their users' access rights
> > > (Foreman roles) in that identity server. In IPA, users can be members
> > > of groups, so some mapping of group membership in IPA to roles in
> > > Foreman seems like feasible solution. Does Foreman already have some
> > > mechanism to assign roles based on groups? If not, would that (ability
> > > of Foreman admin to set up group -> roles mapping) be a viable option?
> > > Or should we keep it simple and just do some text mapping – for
> > > example any group prefixed with "Foreman_" would map to the role with
> > > the same name as the rest of the group name?
> >
> > We have something similar in Katello and this mapping seems like a solution
> > for SSO with roles propagation. +1 from my side.
>
> Which approach do you have in mind – some database table mapping
> group names to roles, or the text conversion based?
>
> Can you point me to the relevant code in Katello?
Today, if the ldap_roles is turned on on every request it checks the ldap mapping if specified:
There's not the REMOTE_USER_* used for this, but the Katello is calling the
LDAP server directly. I like the REMOTE_USER_* approach better, as it
moves the responsibility outside of the Katello server.
– Ivan
···
----- Original Message -----
> On Tue, Oct 29, 2013 at 04:04:34AM -0400, Ivan Necas wrote:
Thank you,
–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
When is this coming to Foreman? Is it already there for the LDAP auth
sources?
We might want to have one set of group -> roles mapping per AuthSource
but in general getting the list of groups and converting to list of
roles is what is probably called for.
···
On Tue, Oct 29, 2013 at 04:48:17AM -0400, Ivan Necas wrote:
>
> > > We have something similar in Katello and this mapping seems like a solution
> > > for SSO with roles propagation. +1 from my side.
> >
> > Which approach do you have in mind -- some database table mapping
> > group names to roles, or the text conversion based?
> >
> > Can you point me to the relevant code in Katello?
>
> Today, if the ldap_roles is turned on on every request it checks the ldap mapping if specified:
>
> https://github.com/Katello/katello/blob/master/app/controllers/api/api_controller.rb#L46
>
> Which triggers this if the mapping is set and doesn't fit:
>
> https://github.com/Katello/katello/blob/master/app/models/user.rb#L326
>
> The mapping to LDAP groups is set in Roles editing. This model is used for
> storing the info:
>
> https://github.com/Katello/katello/blob/master/app/models/ldap_group_role.rb
>
> with the following schema:
>
> https://github.com/Katello/katello/blob/master/db/schema.rb#L321
>
> There's not the REMOTE_USER_* used for this, but the Katello is calling the
> LDAP server directly. I like the REMOTE_USER_* approach better, as it
> moves the responsibility outside of the Katello server.
–
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
