On Thu, Aug 04, 2011 at 06:31:48PM -0400, Dmitri Pal wrote:
On 08/04/2011 01:42 PM, Mo Morsi wrote:
> On 07/28/2011 07:04 PM, Dmitri Pal wrote:
>> On 07/28/2011 06:51 PM, Mo Morsi wrote:
>>> Some of these have been discussed, while some of these have been sitting
>>> on my backlog for ages.
>>>
>>> -------------------
>>>
>
Sure. The only problem I see is that once you implement something like
SSL you are most likely not going to use GSSAPI or OAuth. The reverse is
true too. If you go with OAuth you are not going to implement SSL unless
absolutely pressed and you would try to move as far as you can with
whatever technology you picked making it even harder to change later on.
There is plenty of examples. Take Candlepin and BouncyCastle or Katello
and OAuth. They made the choice. They get issues but they try to
overcome them as solutions seem to be incrementally simpler than ripping
and replacing. So claims that we will integrate with IPA later and for
now we will use something simpler most likely would end up in more work
for everyone later as existing solution would have to be reworked
significantly or IPA would be tasked with new things that it currently
does not have capability of. The worst would be that the design choices
would be made that it would be impossible to switch. Think about openssl
and nss. NSS is certified and much more secure. It is preferred crypto
module but openssl is simpler. On multiple occasions use of openssl
created situations when it is impossible to switch to NSS as some of
things like revealing private key in clear are normal in openssl and a
no go in NSS. I want to avoid such decisions as much as possible.
So the $64k question is, can we get something with OAuth-like
simplicity and no Kerberos requirement, via IPA?
--Hugh
>>> -------------------
>>>
>>> Identity:
>>>
>>> Currently we use a users table in the db to store user identity. We need
>>> to be able to integrate a user store from LDAP, whether it be a server
>>> we setup ourselves via configure or an external one we integrate in
>>> (both need to be supported)
>>>
>> IPA is your friend. We are working on the IPA VM so that it it can be
>> easy to use and develop against.
>>
> In general I don't like requiring a VM to use / install aeolus (its fine
> if its an optional feature). If we do, people with older system and/or
> without a virtualization infrastructure can't use Aeolus.
>
> -Mo
> _______________________________________________
> aeolus-devel mailing list
> aeolus-devel(a)lists.fedorahosted.org
>
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
--
== 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