Advantages:
The main feature of this change will be token-based authentication - that
means after the user was somehow authenticated, he will receive a temporary
token that will be used to authenticate on all subsequent calls. The
lifetime of the token is managed automatically, and may be configured.
The user identity is managed by Devise: In the foreman code all we will
need to do is add :user_authenticate! filter for actions that should be
protected. The user model will be available for us in the current_user
helper method.
Devise also manages the username-password pair authentication, so it
handles the login process (including password verification), password
renewal and so on.
Once we start using Devise we will be able to use OmniAuth strategies to
further expand the spectrum of authentication mechanisms that are supported
by Foreman. Basically, if you have already authenticated somewhere, Foreman
will be able to use that information and will not require to identify the
user again. OmniAuth supports many authentication services, including those
used by organizations such as SAML, OpenID, Kerberos, WS-Federation, ADFS.
The complete list of authentication strategies is here
<https://github.com/intridea/omniauth/wiki/List-of-Strategies>.
As a side effect, there will be no difference between API and GUI
authentication mechanisms, which simplifies the code. This way puts us
closer to a single page applications that will be able to communicate with
Foreman.
Pitfalls:
Heavy Devise views customization to match the current foreman login
form look and feel
Possible painful passwords migration - as far as I have seen, Devise
manages passwords differently.
More state stored in Hammer, due to the need of token storage.
we already have integration with FreeIPA which gives us further
integration with pretty much everything in the IPA domain. AFAIK Foreman
already used Devise for some time, or it was discussed already at least
and it was decided not to use it.
I think you can leverage Apache httpd to do similar integration as
FreeIPA does today.
I would be glad to see the old discussions about using Devise, maybe the
gem has grown up since then?
About FreeIPA: I am in no way an expert in this product, but from what I
have read about it, it's an authentication provider. So actually, foreman
will need to authenticate
its users against a FreeIPA server, if this is the server of choice for
managing corporate users. For the Apache, there is mod_auth_kerb that
authenticates Kerberos users.
It's still not all the work wee need (and actually it's Devise's domain),
once we have authenticated the user, we need to create the appropriate
model in our DB. Another problem
is that it's Apache-specific, that means on other servers we will need to
reinvent this mechanism. For this we have the OmniAuth, it abstracts away
how did we authenticate
the user and returns a clear hash with all the user info that it managed to
extract. Next step will be of course finding the model corresponding to
this info (which is done by Devise)
···
On Tuesday, February 10, 2015 at 2:33:05 PM UTC+2, Lukas Zapletal wrote:
>
> Hello,
>
> > Advantages:
>
> we already have integration with FreeIPA which gives us further
> integration with pretty much everything in the IPA domain. AFAIK Foreman
> already used Devise for some time, or it was discussed already at least
> and it was decided not to use it.
>
> I think you can leverage Apache httpd to do similar integration as
> FreeIPA does today.
>
> --
> Later,
> Lukas #lzap Zapletal
>
I have no idea on the state of the conversation, but I want to chime in: using Devise + omniauth would make my life easier. I need to auth against an SSO provider for which there are off the shelf omniauth plugins. A few lines of configuration and I'd be set.
Apache modules for auth have been a miserable and fragile workaround.
Cheers,
Aaron
···
> On Feb 10, 2015, at 6:33 AM, Shim Shtein wrote:
>
> First thanks for the response.
>
> I would be glad to see the old discussions about using Devise, maybe the gem has grown up since then?
>
> About FreeIPA: I am in no way an expert in this product, but from what I have read about it, it's an authentication provider. So actually, foreman will need to authenticate
> its users against a FreeIPA server, if this is the server of choice for managing corporate users. For the Apache, there is mod_auth_kerb that authenticates Kerberos users.
> It's still not all the work wee need (and actually it's Devise's domain), once we have authenticated the user, we need to create the appropriate model in our DB. Another problem
> is that it's Apache-specific, that means on other servers we will need to reinvent this mechanism. For this we have the OmniAuth, it abstracts away how did we authenticate
> the user and returns a clear hash with all the user info that it managed to extract. Next step will be of course finding the model corresponding to this info (which is done by Devise)
>
>
>
>
>
>> On Tuesday, February 10, 2015 at 2:33:05 PM UTC+2, Lukas Zapletal wrote:
>> Hello,
>>
>> > Advantages:
>>
>> we already have integration with FreeIPA which gives us further
>> integration with pretty much everything in the IPA domain. AFAIK Foreman
>> already used Devise for some time, or it was discussed already at least
>> and it was decided not to use it.
>>
>> I think you can leverage Apache httpd to do similar integration as
>> FreeIPA does today.
>>
>> --
>> Later,
>> Lukas #lzap Zapletal
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
It's nice to hear that it will be a useful direction. It was my own hunch
too.
···
On Tuesday, February 10, 2015 at 5:43:58 PM UTC+2, Aaron Stone wrote:
>
> I have no idea on the state of the conversation, but I want to chime in:
> using Devise + omniauth would make my life easier. I need to auth against
> an SSO provider for which there are off the shelf omniauth plugins. A few
> lines of configuration and I'd be set.
>
> Apache modules for auth have been a miserable and fragile workaround.
>
> Cheers,
> Aaron
>
> On Feb 10, 2015, at 6:33 AM, Shim Shtein <shtei...@gmail.com > > wrote:
>
> First thanks for the response.
>
> I would be glad to see the old discussions about using Devise, maybe the
> gem has grown up since then?
>
> About FreeIPA: I am in no way an expert in this product, but from what I
> have read about it, it's an authentication *provider.* So actually,
> foreman will need to authenticate
> its users against a FreeIPA server, if this is the server of choice for
> managing corporate users. For the Apache, there is mod_auth_kerb that
> authenticates Kerberos users.
> It's still not all the work wee need (and actually it's Devise's domain),
> once we have authenticated the user, we need to create the appropriate
> model in our DB. Another problem
> is that it's Apache-specific, that means on other servers we will need to
> reinvent this mechanism. For this we have the OmniAuth, it abstracts away
> how did we authenticate
> the user and returns a clear hash with all the user info that it managed
> to extract. Next step will be of course finding the model corresponding to
> this info (which is done by Devise)
>
>
>
>
>
> On Tuesday, February 10, 2015 at 2:33:05 PM UTC+2, Lukas Zapletal wrote:
>>
>> Hello,
>>
>> > Advantages:
>>
>> we already have integration with FreeIPA which gives us further
>> integration with pretty much everything in the IPA domain. AFAIK Foreman
>> already used Devise for some time, or it was discussed already at least
>> and it was decided not to use it.
>>
>> I think you can leverage Apache httpd to do similar integration as
>> FreeIPA does today.
>>
>> --
>> Later,
>> Lukas #lzap Zapletal
>>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> I would be glad to see the old discussions about using Devise, maybe the
> gem has grown up since then?
I searched this list and hit no results, but I think this was years ago
when Katello used devise gem and it was a separate project. Now Katello
is a plugin into Foreman. So I was little wrong.
> About FreeIPA: I am in no way an expert in this product, but from what I
> have read about it, it's an authentication provider. So actually, foreman
> will need to authenticate
> its users against a FreeIPA server, if this is the server of choice for
> managing corporate users. For the Apache, there is mod_auth_kerb that
> authenticates Kerberos users.
> It's still not all the work wee need (and actually it's Devise's domain),
> once we have authenticated the user, we need to create the appropriate
> model in our DB. Another problem
> is that it's Apache-specific, that means on other servers we will need to
> reinvent this mechanism. For this we have the OmniAuth, it abstracts away
> how did we authenticate
> the user and returns a clear hash with all the user info that it managed to
> extract. Next step will be of course finding the model corresponding to
> this info (which is done by Devise)
I am not expert in this area as well, but the way I see this is Foreman
does today more than Devise. We have rich permissions API and some other
things hooked on User and Role models.
ps:
There was an excellent talk on this topic this weekend:
> It was recorded, you should find it on YouTube (RedHatCzech channel).
Just for the record, because it's hard to find it:
This is multi-camera recording, Adobe Flash needed (yeah) and be sure to
switch over to "Using OS-level identity, authentication, and access
control for Web applications". Foremen inside!
First of all we need to separate two concepts: there is the authentication
and there is the authorization.
Authentication is about deciding who is running the request.
Authorization on the other hand is about deciding what this user can do
with a system.
Devise handles the first one: its output is the user in a form of model.
Our permissions API is indeed very nice and complicated, and it deals with
the latter (authorization).
That means that all the code that deals with the question which resources
and which actions should
be available for the user will stay almost intact.
I really recommend watching the talk Lukas just sent. Also I would suggest
to look at the recent development of the apache modules (that's what
the talk is actually about).
Although I don't personally see many benefits of using Devise for us (most
of the things we need we already have: although you can't log in to Foreman using your
LastFM credentials :). On the other hand, if it makes life easier for other, why not…
Also, refactoring time is a good time spent
However, before we move any further with this, I would suggest:
looking at possibilities to keep the current internal authentication working: invalidating all the user's passwords seems to me quite invasive for just the fact that we want to add token-based authentication. I guess it might be another Devise auth provider…
keeping the Apache-based authentication working: frankly, given I was a sysadmin, I would still prefer using the apache-module and giving the permissions for the keytab to the apache as opposed to the foreman itself: the folks behind mod_authnz_pam and mod_lookup_identity are doing authentication for living. Not being able to use that would be a show-stopper for me. On the other hand, making that working seamlessly with devise would be an interesting contribution for both the apache modules and the Ruby community
– Ivan
···
----- Original Message -----
> First of all we need to separate two concepts: there is the authentication
> and there is the authorization.
>
> Authentication is about deciding *who* is running the request.
> Authorization on the other hand is about deciding *what* this user can do
> with a system.
>
> Devise handles the first one: its output is the user in a form of model.
> Our permissions API is indeed very nice and complicated, and it deals with
> the latter (authorization).
> That means that all the code that deals with the question which resources
> and which actions should
> be available for the user will stay almost intact.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Our authentication mechanisms also provide some authorisation data, i.e.
the group memberships. User groups map to external user group models,
which represent something like an LDAP group object or groups specified
by Apache modules.
···
On 11/02/15 07:24, Shim Shtein wrote:
> First of all we need to separate two concepts: there is the
> authentication and there is the authorization.
>
> Authentication is about deciding _who_ is running the request.
> Authorization on the other hand is about deciding _what_ this user can
> do with a system.
>
> Devise handles the first one: its output is the user in a form of model.
> Our permissions API is indeed very nice and complicated, and it deals
> with the latter (authorization).
> That means that all the code that deals with the question which
> resources and which actions should
> be available for the user will stay almost intact.
I am not attached to the authorization framework. Foreman's is fine.
Cheers,
Aaron
···
On Tue, Feb 10, 2015 at 11:24 PM, Shim Shtein wrote:
First of all we need to separate two concepts: there is the authentication
and there is the authorization.
Authentication is about deciding who is running the request.
Authorization on the other hand is about deciding what this user can do
with a system.
Devise handles the first one: its output is the user in a form of model.
Our permissions API is indeed very nice and complicated, and it deals with
the latter (authorization).
That means that all the code that deals with the question which resources
and which actions should
be available for the user will stay almost intact.
I think using Devise would clean up existing code and allow us to add more
identity providers. IIRC there was no discussion of adding it to Foreman yet,
just few comments that using Devise would be nice. It was used in Katello
before enginification so packaging shouldn't be too hard even though there are
some dependencies.
So I'd +1 to use Devise but only if we keep all methods we currently support
(which means rewriting them as warden strategies). The question is about
priority, if the only major benefit is using new tickets feature, I think we
could add this to our existing scheme. If there's interest in more providers
and refactoring (always good) then using Devise makes sense to me.
Regarding FreeIPA and authentication/authorization concerns, my understanding
is that Devise is just a "framework" for writing authentication (warden)
strategies and provides few "helpers" (it's an engine) to make building login
screen, forgot password and related features easy. Parsing user groups set as
ENV vars etc. should be possible in strategy so I don't think that would be a
blocker.
···
--
Marek
On Wednesday 11 of February 2015 03:31:29 Ivan Necas wrote:
I really recommend watching the talk Lukas just sent. Also I would suggest
to look at the recent development of the apache modules (that’s what
the talk is actually about).
Although I don’t personally see many benefits of using Devise for us (most
of the things we need we already have: although you can’t log in to Foreman
using your LastFM credentials :). On the other hand, if it makes life
easier for other, why not… Also, refactoring time is a good time spent
However, before we move any further with this, I would suggest:
looking at possibilities to keep the current internal authentication
working: invalidating all the user’s passwords seems to me quite invasive
for just the fact that we want to add token-based authentication. I guess
it might be another Devise auth provider…
keeping the Apache-based authentication working: frankly, given I was a
sysadmin, I would still prefer using the apache-module and giving the
permissions for the keytab to the apache as opposed to the foreman itself:
the folks behind mod_authnz_pam and mod_lookup_identity are doing
authentication for living. Not being able to use that would be a
show-stopper for me. On the other hand, making that working seamlessly with
devise would be an interesting contribution for both the apache modules and
the Ruby community
– Ivan
----- Original Message -----
First of all we need to separate two concepts: there is the authentication
and there is the authorization.
Authentication is about deciding who is running the request.
Authorization on the other hand is about deciding what this user can do
with a system.
Devise handles the first one: its output is the user in a form of model.
Our permissions API is indeed very nice and complicated, and it deals with
the latter (authorization).
That means that all the code that deals with the question which resources
and which actions should
be available for the user will stay almost intact.
About LDAP
For some reasons current version of LDAP OmniAuth provider does not provide
group membership.
I don't think it would be too difficult to add this kind of info to the
response.
About the concerns for the internal authentication: I understand that the
current data is important to keep, it should be possible to migrate it
without destroying.
About Apache: the modules will still remain there, they are executed before
the middleware kicks in, so all the info from modules should be available
to the strategy.
If the info is not extracted, we can always build a strategy that will do
it. The same applies to FreeIPA, I do think that writing a proper strategy
for FreeeIPA login
would be very beneficial to all Ruby users.
> About LDAP
> For some reasons current version of LDAP OmniAuth provider does not provide
> group membership.
> I don't think it would be too difficult to add this kind of info to the
> response.
> About the concerns for the internal authentication: I understand that the
> current data is important to keep, it should be possible to migrate it
> without destroying.
> About Apache: the modules will still remain there, they are executed before
> the middleware kicks in, so all the info from modules should be available to
> the strategy.
> If the info is not extracted, we can always build a strategy that will do it.
> The same applies to FreeIPA, I do think that writing a proper strategy for
> FreeeIPA login
> would be very beneficial to all Ruby users.
If these things that are already working are taken care off, no other issues
– Ivan
···
----- Original Message -----
from my side to move forward with this initiative.
