12:15 p.m.
Hi,
there are two things we need for sharing user identity in Katello and
Conductor:
1) Single sign on for Katello and Conductor:
Simplest solution is using 2 legged oauth as proposed in a mail before
(katello already uses this for accessing pulp and candlepin). In short:
auth is done on application level by sharing secret token, provider app
trusts consumer app that consumer already authenticated the user which
it passes to provider. This solution should be pretty easy to implement.
If this is not acceptable for some reason, we could consider using some
central auth service (CAS).
2) Authenticate against same external service in Katello and Conductor:
Katello and Conductor should support authentication against external
auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
auth framework in both apps so we will be able to support same
authentication methods. Katello is far before conductor in
authentication, it uses warden and supports various auth strategies for
it (LDAP, SSO over http headers, certificates). I heard there was some
talk about switching to Omniauth, but I didn't find it on mailing list.
So there are two options here:
1) conductor switches to warden - this shouldn't be so difficult as we
can copy from Katello :). Also Omniauth is not packaged in Fedora,
Warden is.
2) both Katello and Conductor switch to Omniauth. I'm not sure if this
is required or optional step, Ken: you suggested switching to Omniauth,
could you please reply with your opinion about warden/omniauth (or point
me to older discussion)?
Jan
1:20 p.m.
On 08/12/2011 07:15 PM, Jan Provazník wrote:
Hi,
there are two things we need for sharing user identity in Katello and
Conductor:
1) Single sign on for Katello and Conductor:
Simplest solution is using 2 legged oauth as proposed in a mail before
(katello already uses this for accessing pulp and candlepin). In short:
auth is done on application level by sharing secret token, provider app
trusts consumer app that consumer already authenticated the user which
it passes to provider. This solution should be pretty easy to implement.
If this is not acceptable for some reason, we could consider using some
central auth service (CAS).
2) Authenticate against same external service in Katello and Conductor:
Katello and Conductor should support authentication against external
auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
auth framework in both apps so we will be able to support same
authentication methods. Katello is far before conductor in
authentication, it uses warden and supports various auth strategies for
it (LDAP, SSO over http headers, certificates). I heard there was some
talk about switching to Omniauth, but I didn't find it on mailing list.
So there are two options here:
1) conductor switches to warden - this shouldn't be so difficult as we
can copy from Katello :). Also Omniauth is not packaged in Fedora,
Warden is.
2) both Katello and Conductor switch to Omniauth. I'm not sure if this
is required or optional step, Ken: you suggested switching to Omniauth,
could you please reply with your opinion about warden/omniauth (or point
me to older discussion)?
Jan
Hi Katello folks,
what are your plans about Warden vs. Omniauth - are you going to switch
to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
and Conductor - is 2legged OAuth the way you want to go?
Jan
2:39 p.m.
On 08/17/2011 11:20 AM, Jan Provazník wrote:
On 08/12/2011 07:15 PM, Jan Provazník wrote:
> Hi,
> there are two things we need for sharing user identity in Katello and
> Conductor:
>
> 1) Single sign on for Katello and Conductor:
> Simplest solution is using 2 legged oauth as proposed in a mail before
> (katello already uses this for accessing pulp and candlepin). In short:
> auth is done on application level by sharing secret token, provider app
> trusts consumer app that consumer already authenticated the user which
> it passes to provider. This solution should be pretty easy to implement.
>
> If this is not acceptable for some reason, we could consider using some
> central auth service (CAS).
>
> 2) Authenticate against same external service in Katello and Conductor:
> Katello and Conductor should support authentication against external
> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
> auth framework in both apps so we will be able to support same
> authentication methods. Katello is far before conductor in
> authentication, it uses warden and supports various auth strategies for
> it (LDAP, SSO over http headers, certificates). I heard there was some
> talk about switching to Omniauth, but I didn't find it on mailing list.
>
> So there are two options here:
> 1) conductor switches to warden - this shouldn't be so difficult as we
> can copy from Katello :). Also Omniauth is not packaged in Fedora,
> Warden is.
> 2) both Katello and Conductor switch to Omniauth. I'm not sure if this
> is required or optional step, Ken: you suggested switching to Omniauth,
> could you please reply with your opinion about warden/omniauth (or point
> me to older discussion)?
>
> Jan
Hi Katello folks,
what are your plans about Warden vs. Omniauth - are you going to switch
to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
and Conductor - is 2legged OAuth the way you want to go?
I'm OK with moving to Omniauth, especially if it simplifies and
standardizes our project's auth mechanism. The migration from Warden ->
Omniauth didn't look too hard but we just haven't put it on our backlog
to get done in the near term. We can re-prioritize that if necessary.
As far as SSO, we have had good success with OAuth between Katello ->
Pulp/Candlepin (the subsystems underneath Katello) and would recommend
it as well for auth between Katello <-> Conductor.
Mike
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650.254.4248
2:43 p.m.
On Wed, Aug 17, 2011 at 12:39:37PM -0700, Mike McCune wrote:
On 08/17/2011 11:20 AM, Jan Provazník wrote:
> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>> Hi,
>> there are two things we need for sharing user identity in Katello and
>> Conductor:
>>
>> 1) Single sign on for Katello and Conductor:
>> Simplest solution is using 2 legged oauth as proposed in a mail before
>> (katello already uses this for accessing pulp and candlepin). In short:
>> auth is done on application level by sharing secret token, provider app
>> trusts consumer app that consumer already authenticated the user which
>> it passes to provider. This solution should be pretty easy to implement.
>>
>> If this is not acceptable for some reason, we could consider using some
>> central auth service (CAS).
>>
>> 2) Authenticate against same external service in Katello and Conductor:
>> Katello and Conductor should support authentication against external
>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>> auth framework in both apps so we will be able to support same
>> authentication methods. Katello is far before conductor in
>> authentication, it uses warden and supports various auth strategies for
>> it (LDAP, SSO over http headers, certificates). I heard there was some
>> talk about switching to Omniauth, but I didn't find it on mailing list.
>>
>> So there are two options here:
>> 1) conductor switches to warden - this shouldn't be so difficult as we
>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>> Warden is.
>> 2) both Katello and Conductor switch to Omniauth. I'm not sure if this
>> is required or optional step, Ken: you suggested switching to Omniauth,
>> could you please reply with your opinion about warden/omniauth (or point
>> me to older discussion)?
>>
>> Jan
>
> Hi Katello folks,
> what are your plans about Warden vs. Omniauth - are you going to switch
> to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
> and Conductor - is 2legged OAuth the way you want to go?
>
I'm OK with moving to Omniauth, especially if it simplifies and
standardizes our project's auth mechanism. The migration from Warden ->
Omniauth didn't look too hard but we just haven't put it on our backlog
to get done in the near term. We can re-prioritize that if necessary.
As far as SSO, we have had good success with OAuth between Katello ->
Pulp/Candlepin (the subsystems underneath Katello) and would recommend
it as well for auth between Katello <-> Conductor.
Ken, Jay Guiditta, you guys were the leading voices calling for
Omniauth over Warden -- can you give Mike some idea of the level of
difficulty to migrate and the reasons we would do that rather than
just going with what they already have (Warden)?
Thanks,
--Hugh
--
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
== http://aeolusproject.org ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey
3:01 p.m.
On Wed, 2011-08-17 at 15:43 -0400, Hugh Brock wrote:
On Wed, Aug 17, 2011 at 12:39:37PM -0700, Mike McCune wrote:
> On 08/17/2011 11:20 AM, Jan Provazník wrote:
> > On 08/12/2011 07:15 PM, Jan Provazník wrote:
> >> Hi,
> >> there are two things we need for sharing user identity in Katello and
> >> Conductor:
> >>
> >> 1) Single sign on for Katello and Conductor:
> >> Simplest solution is using 2 legged oauth as proposed in a mail before
> >> (katello already uses this for accessing pulp and candlepin). In short:
> >> auth is done on application level by sharing secret token, provider app
> >> trusts consumer app that consumer already authenticated the user which
> >> it passes to provider. This solution should be pretty easy to implement.
> >>
> >> If this is not acceptable for some reason, we could consider using some
> >> central auth service (CAS).
> >>
> >> 2) Authenticate against same external service in Katello and Conductor:
> >> Katello and Conductor should support authentication against external
> >> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
> >> auth framework in both apps so we will be able to support same
> >> authentication methods. Katello is far before conductor in
> >> authentication, it uses warden and supports various auth strategies for
> >> it (LDAP, SSO over http headers, certificates). I heard there was some
> >> talk about switching to Omniauth, but I didn't find it on mailing
list.
> >>
> >> So there are two options here:
> >> 1) conductor switches to warden - this shouldn't be so difficult as
we
> >> can copy from Katello :). Also Omniauth is not packaged in Fedora,
> >> Warden is.
> >> 2) both Katello and Conductor switch to Omniauth. I'm not sure if
this
> >> is required or optional step, Ken: you suggested switching to Omniauth,
> >> could you please reply with your opinion about warden/omniauth (or point
> >> me to older discussion)?
> >>
> >> Jan
> >
> > Hi Katello folks,
> > what are your plans about Warden vs. Omniauth - are you going to switch
> > to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
> > and Conductor - is 2legged OAuth the way you want to go?
> >
>
> I'm OK with moving to Omniauth, especially if it simplifies and
> standardizes our project's auth mechanism. The migration from Warden ->
> Omniauth didn't look too hard but we just haven't put it on our backlog
> to get done in the near term. We can re-prioritize that if necessary.
>
> As far as SSO, we have had good success with OAuth between Katello ->
> Pulp/Candlepin (the subsystems underneath Katello) and would recommend
> it as well for auth between Katello <-> Conductor.
Ken, Jay Guiditta, you guys were the leading voices calling for
Omniauth over Warden -- can you give Mike some idea of the level of
difficulty to migrate and the reasons we would do that rather than
just going with what they already have (Warden)?
To clarify, I have no issues with warden (as I am just about to start
researching auth options to replace authlogic for this feature, and know
nothing about warden yet). What I think I said was that I knew of
omniauth and had heard good things about it. That said, this was a
while back, and I do not recall what about it was particularly good,
trying to look into this more today/tomorrow. One of our sprint tasks
on the infra side was to look into options and see what looked to be the
most promising. Due to other obligations, I am just starting this now,
so I have no strong opinion in any direction yet (though I would say I
prefer a rack-based solution to anything rails-specific, to allow
greater flexibility in type of ruby app that can use it).
Nutshell - if there is nothing compelling about a non-warden solution,
then I would favor keeping it so both projects dont have to change their
entire auth system.
-j
Thanks,
--Hugh
2:58 p.m.
On 08/17/2011 03:39 PM, Mike McCune wrote:
On 08/17/2011 11:20 AM, Jan Provazník wrote:
> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>> Hi,
>> there are two things we need for sharing user identity in Katello and
>> Conductor:
>>
>> 1) Single sign on for Katello and Conductor:
>> Simplest solution is using 2 legged oauth as proposed in a mail before
>> (katello already uses this for accessing pulp and candlepin). In short:
>> auth is done on application level by sharing secret token, provider app
>> trusts consumer app that consumer already authenticated the user which
>> it passes to provider. This solution should be pretty easy to implement.
>>
>> If this is not acceptable for some reason, we could consider using some
>> central auth service (CAS).
>>
>> 2) Authenticate against same external service in Katello and Conductor:
>> Katello and Conductor should support authentication against external
>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>> auth framework in both apps so we will be able to support same
>> authentication methods. Katello is far before conductor in
>> authentication, it uses warden and supports various auth strategies for
>> it (LDAP, SSO over http headers, certificates). I heard there was some
>> talk about switching to Omniauth, but I didn't find it on mailing list.
>>
>> So there are two options here:
>> 1) conductor switches to warden - this shouldn't be so difficult as we
>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>> Warden is.
>> 2) both Katello and Conductor switch to Omniauth. I'm not sure if this
>> is required or optional step, Ken: you suggested switching to Omniauth,
>> could you please reply with your opinion about warden/omniauth (or point
>> me to older discussion)?
>>
>> Jan
>
> Hi Katello folks,
> what are your plans about Warden vs. Omniauth - are you going to switch
> to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
> and Conductor - is 2legged OAuth the way you want to go?
>
I'm OK with moving to Omniauth, especially if it simplifies and
standardizes our project's auth mechanism. The migration from Warden ->
Omniauth didn't look too hard but we just haven't put it on our backlog
to get done in the near term. We can re-prioritize that if necessary.
If there value to move to Omniauth? I am all for not changing things
that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
rules is not compelling.
As far as SSO, we have had good success with OAuth between Katello ->
Pulp/Candlepin (the subsystems underneath Katello) and would recommend
it as well for auth between Katello<-> Conductor.
We have the katello API via oauth on the backlog for this sprint.
-- bk
3:47 p.m.
On 08/17/2011 12:58 PM, Bryan Kearney wrote:
On 08/17/2011 03:39 PM, Mike McCune wrote:
> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>> Hi,
>>> there are two things we need for sharing user identity in Katello and
>>> Conductor:
>>>
>>> 1) Single sign on for Katello and Conductor:
>>> Simplest solution is using 2 legged oauth as proposed in a mail before
>>> (katello already uses this for accessing pulp and candlepin). In short:
>>> auth is done on application level by sharing secret token, provider app
>>> trusts consumer app that consumer already authenticated the user which
>>> it passes to provider. This solution should be pretty easy to implement.
>>>
>>> If this is not acceptable for some reason, we could consider using some
>>> central auth service (CAS).
>>>
>>> 2) Authenticate against same external service in Katello and Conductor:
>>> Katello and Conductor should support authentication against external
>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>>> auth framework in both apps so we will be able to support same
>>> authentication methods. Katello is far before conductor in
>>> authentication, it uses warden and supports various auth strategies for
>>> it (LDAP, SSO over http headers, certificates). I heard there was some
>>> talk about switching to Omniauth, but I didn't find it on mailing list.
>>>
>>> So there are two options here:
>>> 1) conductor switches to warden - this shouldn't be so difficult as
we
>>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>>> Warden is.
>>> 2) both Katello and Conductor switch to Omniauth. I'm not sure if
this
>>> is required or optional step, Ken: you suggested switching to Omniauth,
>>> could you please reply with your opinion about warden/omniauth (or point
>>> me to older discussion)?
>>>
>>> Jan
>>
>> Hi Katello folks,
>> what are your plans about Warden vs. Omniauth - are you going to switch
>> to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
>> and Conductor - is 2legged OAuth the way you want to go?
>>
>
> I'm OK with moving to Omniauth, especially if it simplifies and
> standardizes our project's auth mechanism. The migration from Warden ->
> Omniauth didn't look too hard but we just haven't put it on our backlog
> to get done in the near term. We can re-prioritize that if necessary.
If there value to move to Omniauth? I am all for not changing things
that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
rules is not compelling.
I was under the impression that there was some other benefit beyond just
a standardization but I'm forgetting what it was :)
Mike
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650.254.4248
4:18 p.m.
On Wed, 2011-08-17 at 13:47 -0700, Mike McCune wrote:
On 08/17/2011 12:58 PM, Bryan Kearney wrote:
> On 08/17/2011 03:39 PM, Mike McCune wrote:
>> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>>> Hi,
>>>> there are two things we need for sharing user identity in Katello and
>>>> Conductor:
>>>>
>>>> 1) Single sign on for Katello and Conductor:
>>>> Simplest solution is using 2 legged oauth as proposed in a mail before
>>>> (katello already uses this for accessing pulp and candlepin). In short:
>>>> auth is done on application level by sharing secret token, provider app
>>>> trusts consumer app that consumer already authenticated the user which
>>>> it passes to provider. This solution should be pretty easy to
implement.
>>>>
>>>> If this is not acceptable for some reason, we could consider using some
>>>> central auth service (CAS).
>>>>
>>>> 2) Authenticate against same external service in Katello and Conductor:
>>>> Katello and Conductor should support authentication against external
>>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>>>> auth framework in both apps so we will be able to support same
>>>> authentication methods. Katello is far before conductor in
>>>> authentication, it uses warden and supports various auth strategies for
>>>> it (LDAP, SSO over http headers, certificates). I heard there was some
>>>> talk about switching to Omniauth, but I didn't find it on mailing
list.
>>>>
>>>> So there are two options here:
>>>> 1) conductor switches to warden - this shouldn't be so
difficult as we
>>>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>>>> Warden is.
>>>> 2) both Katello and Conductor switch to Omniauth. I'm not sure
if this
>>>> is required or optional step, Ken: you suggested switching to Omniauth,
>>>> could you please reply with your opinion about warden/omniauth (or
point
>>>> me to older discussion)?
>>>>
>>>> Jan
>>>
>>> Hi Katello folks,
>>> what are your plans about Warden vs. Omniauth - are you going to switch
>>> to Omniauth or keep Warden? Also what's your opinion on SSO for Katello
>>> and Conductor - is 2legged OAuth the way you want to go?
>>>
>>
>> I'm OK with moving to Omniauth, especially if it simplifies and
>> standardizes our project's auth mechanism. The migration from Warden ->
>> Omniauth didn't look too hard but we just haven't put it on our backlog
>> to get done in the near term. We can re-prioritize that if necessary.
>
> If there value to move to Omniauth? I am all for not changing things
> that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
> rules is not compelling.
I was under the impression that there was some other benefit beyond just
a standardization but I'm forgetting what it was :)
Does Katello currently support ldap as an oauth strategy? If not, where
is it on the todo list (hi/low)?
Thinking if you already have ldap there is less reason to even be
discussing a switch here.
-j
Mike
5:16 p.m.
On 08/17/2011 02:18 PM, Jason Guiditta wrote:
On Wed, 2011-08-17 at 13:47 -0700, Mike McCune wrote:
> On 08/17/2011 12:58 PM, Bryan Kearney wrote:
>> On 08/17/2011 03:39 PM, Mike McCune wrote:
>>> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>>>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>>>> Hi,
>>>>> there are two things we need for sharing user identity in Katello
and
>>>>> Conductor:
>>>>>
>>>>> 1) Single sign on for Katello and Conductor:
>>>>> Simplest solution is using 2 legged oauth as proposed in a mail
before
>>>>> (katello already uses this for accessing pulp and candlepin). In
short:
>>>>> auth is done on application level by sharing secret token, provider
app
>>>>> trusts consumer app that consumer already authenticated the user
which
>>>>> it passes to provider. This solution should be pretty easy to
implement.
>>>>>
>>>>> If this is not acceptable for some reason, we could consider using
some
>>>>> central auth service (CAS).
>>>>>
>>>>> 2) Authenticate against same external service in Katello and
Conductor:
>>>>> Katello and Conductor should support authentication against external
>>>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>>>>> auth framework in both apps so we will be able to support same
>>>>> authentication methods. Katello is far before conductor in
>>>>> authentication, it uses warden and supports various auth strategies
for
>>>>> it (LDAP, SSO over http headers, certificates). I heard there was
some
>>>>> talk about switching to Omniauth, but I didn't find it on mailing
list.
>>>>>
>>>>> So there are two options here:
>>>>> 1) conductor switches to warden - this shouldn't be so
difficult as we
>>>>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>>>>> Warden is.
>>>>> 2) both Katello and Conductor switch to Omniauth. I'm not
sure if this
>>>>> is required or optional step, Ken: you suggested switching to
Omniauth,
>>>>> could you please reply with your opinion about warden/omniauth (or
point
>>>>> me to older discussion)?
>>>>>
>>>>> Jan
>>>>
>>>> Hi Katello folks,
>>>> what are your plans about Warden vs. Omniauth - are you going to switch
>>>> to Omniauth or keep Warden? Also what's your opinion on SSO for
Katello
>>>> and Conductor - is 2legged OAuth the way you want to go?
>>>>
>>>
>>> I'm OK with moving to Omniauth, especially if it simplifies and
>>> standardizes our project's auth mechanism. The migration from Warden
->
>>> Omniauth didn't look too hard but we just haven't put it on our
backlog
>>> to get done in the near term. We can re-prioritize that if necessary.
>>
>> If there value to move to Omniauth? I am all for not changing things
>> that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
>> rules is not compelling.
>
> I was under the impression that there was some other benefit beyond just
> a standardization but I'm forgetting what it was :)
Does Katello currently support ldap as an oauth strategy? If not, where
is it on the todo list (hi/low)?
Thinking if you already have ldap there is less reason to even be
discussing a switch here.
-j
yes, we can authenticate to an external LDAP store but not specifically
using OAuth. we have a Warden Strategy for LDAP:
http://git.fedorahosted.org/git/?p=katello.git;a=blob;f=src/config/initia...
Warden::Strategies.add(:ldap) do
[...]
u = User.authenticate_using_ldap!(params[:auth_username],
params[:auth_password])
[...]
Mike
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650.254.4248
9:32 a.m.
On Wed, 2011-08-17 at 15:16 -0700, Mike McCune wrote:
On 08/17/2011 02:18 PM, Jason Guiditta wrote:
> On Wed, 2011-08-17 at 13:47 -0700, Mike McCune wrote:
>> On 08/17/2011 12:58 PM, Bryan Kearney wrote:
>>> On 08/17/2011 03:39 PM, Mike McCune wrote:
>>>> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>>>>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>>>>> Hi,
>>>>>> there are two things we need for sharing user identity in
Katello and
>>>>>> Conductor:
>>>>>>
>>>>>> 1) Single sign on for Katello and Conductor:
>>>>>> Simplest solution is using 2 legged oauth as proposed in a mail
before
>>>>>> (katello already uses this for accessing pulp and candlepin). In
short:
>>>>>> auth is done on application level by sharing secret token,
provider app
>>>>>> trusts consumer app that consumer already authenticated the user
which
>>>>>> it passes to provider. This solution should be pretty easy to
implement.
>>>>>>
>>>>>> If this is not acceptable for some reason, we could consider
using some
>>>>>> central auth service (CAS).
>>>>>>
>>>>>> 2) Authenticate against same external service in Katello and
Conductor:
>>>>>> Katello and Conductor should support authentication against
external
>>>>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use
same
>>>>>> auth framework in both apps so we will be able to support same
>>>>>> authentication methods. Katello is far before conductor in
>>>>>> authentication, it uses warden and supports various auth
strategies for
>>>>>> it (LDAP, SSO over http headers, certificates). I heard there
was some
>>>>>> talk about switching to Omniauth, but I didn't find it on
mailing list.
>>>>>>
>>>>>> So there are two options here:
>>>>>> 1) conductor switches to warden - this shouldn't be
so difficult as we
>>>>>> can copy from Katello :). Also Omniauth is not packaged in
Fedora,
>>>>>> Warden is.
>>>>>> 2) both Katello and Conductor switch to Omniauth. I'm
not sure if this
>>>>>> is required or optional step, Ken: you suggested switching to
Omniauth,
>>>>>> could you please reply with your opinion about warden/omniauth
(or point
>>>>>> me to older discussion)?
>>>>>>
>>>>>> Jan
>>>>>
>>>>> Hi Katello folks,
>>>>> what are your plans about Warden vs. Omniauth - are you going to
switch
>>>>> to Omniauth or keep Warden? Also what's your opinion on SSO for
Katello
>>>>> and Conductor - is 2legged OAuth the way you want to go?
>>>>>
>>>>
>>>> I'm OK with moving to Omniauth, especially if it simplifies and
>>>> standardizes our project's auth mechanism. The migration from
Warden ->
>>>> Omniauth didn't look too hard but we just haven't put it on our
backlog
>>>> to get done in the near term. We can re-prioritize that if necessary.
>>>
>>> If there value to move to Omniauth? I am all for not changing things
>>> that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
>>> rules is not compelling.
>>
>> I was under the impression that there was some other benefit beyond just
>> a standardization but I'm forgetting what it was :)
>
> Does Katello currently support ldap as an oauth strategy? If not, where
> is it on the todo list (hi/low)?
>
> Thinking if you already have ldap there is less reason to even be
> discussing a switch here.
>
> -j
>
yes, we can authenticate to an external LDAP store but not specifically
using OAuth. we have a Warden Strategy for LDAP:
http://git.fedorahosted.org/git/?p=katello.git;a=blob;f=src/config/initia...
Warden::Strategies.add(:ldap) do
[...]
u = User.authenticate_using_ldap!(params[:auth_username],
params[:auth_password])
[...]
Mike
This seems perfectly reasonable to me. I'll look through how the
various strategies in katello are set up to me, but unless someone comes
back with a strong case _against_ warden, I am not seeing anything that
makes me think it is insufficient. Mike (or anyone familiar with the
codebase), could you point me to some of the key places to look at auth
aside from initializer? I can find it on my own, but it would save me
some time hunting around in unfamiliar code.
Quick look tells me you are using net-ldap for that part, have you had
any issues/complaints with it?
Thanks,
-j
2:57 a.m.
On 11-08-18 11:32 AM, Jason Guiditta wrote:
On Wed, 2011-08-17 at 15:16 -0700, Mike McCune wrote:
> On 08/17/2011 02:18 PM, Jason Guiditta wrote:
>> On Wed, 2011-08-17 at 13:47 -0700, Mike McCune wrote:
>>> On 08/17/2011 12:58 PM, Bryan Kearney wrote:
>>>> On 08/17/2011 03:39 PM, Mike McCune wrote:
>>>>> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>>>>>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>>>>>> Hi,
>>>>>>> there are two things we need for sharing user identity in
Katello and
>>>>>>> Conductor:
>>>>>>>
>>>>>>> 1) Single sign on for Katello and Conductor:
>>>>>>> Simplest solution is using 2 legged oauth as proposed in a
mail before
>>>>>>> (katello already uses this for accessing pulp and candlepin).
In short:
>>>>>>> auth is done on application level by sharing secret token,
provider app
>>>>>>> trusts consumer app that consumer already authenticated the
user which
>>>>>>> it passes to provider. This solution should be pretty easy to
implement.
>>>>>>>
>>>>>>> If this is not acceptable for some reason, we could consider
using some
>>>>>>> central auth service (CAS).
>>>>>>>
>>>>>>> 2) Authenticate against same external service in Katello and
Conductor:
>>>>>>> Katello and Conductor should support authentication against
external
>>>>>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to
use same
>>>>>>> auth framework in both apps so we will be able to support
same
>>>>>>> authentication methods. Katello is far before conductor in
>>>>>>> authentication, it uses warden and supports various auth
strategies for
>>>>>>> it (LDAP, SSO over http headers, certificates). I heard
there was some
>>>>>>> talk about switching to Omniauth, but I didn't find it on
mailing list.
>>>>>>>
>>>>>>> So there are two options here:
>>>>>>> 1) conductor switches to warden - this shouldn't
be so difficult as we
>>>>>>> can copy from Katello :). Also Omniauth is not packaged in
Fedora,
>>>>>>> Warden is.
>>>>>>> 2) both Katello and Conductor switch to Omniauth.
I'm not sure if this
>>>>>>> is required or optional step, Ken: you suggested switching to
Omniauth,
>>>>>>> could you please reply with your opinion about
warden/omniauth (or point
>>>>>>> me to older discussion)?
>>>>>>>
>>>>>>> Jan
>>>>>> Hi Katello folks,
>>>>>> what are your plans about Warden vs. Omniauth - are you going to
switch
>>>>>> to Omniauth or keep Warden? Also what's your opinion on SSO
for Katello
>>>>>> and Conductor - is 2legged OAuth the way you want to go?
>>>>>>
>>>>> I'm OK with moving to Omniauth, especially if it simplifies and
>>>>> standardizes our project's auth mechanism. The migration from
Warden ->
>>>>> Omniauth didn't look too hard but we just haven't put it on
our backlog
>>>>> to get done in the near term. We can re-prioritize that if
necessary.
>>>> If there value to move to Omniauth? I am all for not changing things
>>>> that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
>>>> rules is not compelling.
>>> I was under the impression that there was some other benefit beyond just
>>> a standardization but I'm forgetting what it was :)
>> Does Katello currently support ldap as an oauth strategy? If not, where
>> is it on the todo list (hi/low)?
>>
>> Thinking if you already have ldap there is less reason to even be
>> discussing a switch here.
>>
>> -j
>>
> yes, we can authenticate to an external LDAP store but not specifically
> using OAuth. we have a Warden Strategy for LDAP:
>
>
http://git.fedorahosted.org/git/?p=katello.git;a=blob;f=src/config/initia...
>
> Warden::Strategies.add(:ldap) do
> [...]
> u = User.authenticate_using_ldap!(params[:auth_username],
> params[:auth_password])
> [...]
>
>
> Mike
This seems perfectly reasonable to me. I'll look through how the
various strategies in katello are set up to me, but unless someone comes
back with a strong case _against_ warden, I am not seeing anything that
makes me think it is insufficient. Mike (or anyone familiar with the
codebase), could you point me to some of the key places to look at auth
aside from initializer? I can find it on my own, but it would save me
some time hunting around in unfamiliar code.
initializer
(config/initializers/warden.rb) is the main piece. The only
other piece is ApplicationConfiguration module, which is in
config/initializers/app_config.rb
Quick look tells me you are using net-ldap for that part, have you had
any issues/complaints with it?
No issues so far.
-d
Thanks,
-j
_______________________________________________
katello mailing list
katello(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/katello
8:13 a.m.
On 08/17/2011 05:18 PM, Jason Guiditta wrote:
On Wed, 2011-08-17 at 13:47 -0700, Mike McCune wrote:
> On 08/17/2011 12:58 PM, Bryan Kearney wrote:
>> On 08/17/2011 03:39 PM, Mike McCune wrote:
>>> On 08/17/2011 11:20 AM, Jan Provazník wrote:
>>>> On 08/12/2011 07:15 PM, Jan Provazník wrote:
>>>>> Hi,
>>>>> there are two things we need for sharing user identity in Katello
and
>>>>> Conductor:
>>>>>
>>>>> 1) Single sign on for Katello and Conductor:
>>>>> Simplest solution is using 2 legged oauth as proposed in a mail
before
>>>>> (katello already uses this for accessing pulp and candlepin). In
short:
>>>>> auth is done on application level by sharing secret token, provider
app
>>>>> trusts consumer app that consumer already authenticated the user
which
>>>>> it passes to provider. This solution should be pretty easy to
implement.
>>>>>
>>>>> If this is not acceptable for some reason, we could consider using
some
>>>>> central auth service (CAS).
>>>>>
>>>>> 2) Authenticate against same external service in Katello and
Conductor:
>>>>> Katello and Conductor should support authentication against external
>>>>> auth service (AD, LDAP, IPA, maybe more). It makes sense to use same
>>>>> auth framework in both apps so we will be able to support same
>>>>> authentication methods. Katello is far before conductor in
>>>>> authentication, it uses warden and supports various auth strategies
for
>>>>> it (LDAP, SSO over http headers, certificates). I heard there was
some
>>>>> talk about switching to Omniauth, but I didn't find it on mailing
list.
>>>>>
>>>>> So there are two options here:
>>>>> 1) conductor switches to warden - this shouldn't be so
difficult as we
>>>>> can copy from Katello :). Also Omniauth is not packaged in Fedora,
>>>>> Warden is.
>>>>> 2) both Katello and Conductor switch to Omniauth. I'm not
sure if this
>>>>> is required or optional step, Ken: you suggested switching to
Omniauth,
>>>>> could you please reply with your opinion about warden/omniauth (or
point
>>>>> me to older discussion)?
>>>>>
>>>>> Jan
>>>>
>>>> Hi Katello folks,
>>>> what are your plans about Warden vs. Omniauth - are you going to switch
>>>> to Omniauth or keep Warden? Also what's your opinion on SSO for
Katello
>>>> and Conductor - is 2legged OAuth the way you want to go?
>>>>
>>>
>>> I'm OK with moving to Omniauth, especially if it simplifies and
>>> standardizes our project's auth mechanism. The migration from Warden
->
>>> Omniauth didn't look too hard but we just haven't put it on our
backlog
>>> to get done in the near term. We can re-prioritize that if necessary.
>>
>> If there value to move to Omniauth? I am all for not changing things
>> that work unless there is compelling resason. $YOURGEM suxor and $MYGEM
>> rules is not compelling.
>
> I was under the impression that there was some other benefit beyond just
> a standardization but I'm forgetting what it was :)
Does Katello currently support ldap as an oauth strategy? If not, where
is it on the todo list (hi/low)?
Thinking if you already have ldap there is less reason to even be
discussing a switch here.
We have a warden stategy, but have done a bunch of auth changes
recently. We have a task this sprint to make sure it works across
Katello, Pulp, and Candlepin.
-- bk
2:36 a.m.
On 08/12/2011 07:15 PM, Jan Provazník wrote:
Ken: you suggested switching to Omniauth,
could you please reply with your opinion about warden/omniauth (or point
me to older discussion)?
Hey,
as far as I can tell we have chosen Warden because it's simplicity. It's
a rather low-level stack that enables us implement our own methods (e.g.
LDAP etc) quite easily.
What are advantages of the Omniauth? At the first sight it looks like
social-enabled OpenID/Oauth framework oriented on delivering lots of 3rd
leg providers. Do we need such a feature? I was under impression we only
need 2-leg authentication + LDAP integration.
--
Later,
Lukas "lzap" Zapletal
9:51 a.m.
On 08/12/2011 07:15 PM, Jan Provazník wrote:
...
So there are two options here:
1) conductor switches to warden - this shouldn't be so difficult as we
can copy from Katello :). Also Omniauth is not packaged in Fedora,
Warden is.
2) both Katello and Conductor switch to Omniauth. I'm not sure if this
is required or optional step, Ken: you suggested switching to Omniauth,
could you please reply with your opinion about warden/omniauth (or point
me to older discussion)?
Jan
Few findings I didn't mention yet:
- warden is in fedora repo, omniauth not
- for using warden in rails app, it's also required warden_rails gem,
this gem is packaged as rpm in katello repository (not in fedora repo)
- only disadvantage of warden I found as far is that it has to handle
password hashing and ldap auth itself, so it means we will have to
copy/duplicate some code (lib/ldap, lib/util/password) and maintain it
on two places, omniauth _maybe_ (didn't check it) has builtin support
for this
Jan
4641
days inactive
4648
days old
katello@lists.fedorahosted.org
13 comments
7 participants
participants (7)
-
Bryan Kearney -
Dmitri Dolguikh -
Hugh O. Brock -
Jan Provazník -
Jason Guiditta -
Lukas Zapletal -
Mike McCune