On Fri, Jul 29, 2011 at 05:37:12PM -0400, Dmitri Pal wrote:
On 07/29/2011 03:09 PM, Hugh Brock wrote:
[snip]
>
> So, to sum up:
>
> * Conductor (and its catalog manager) and Katello need to share
> user identity, and fairly soon
>
> * Conductor and Factory and Warehouse do not need to share user
> identity
>
> * In fact, Conductor and Katello are the *only* two components in this
> system that need to share identity.
>
> I realize I've just answered my third question above, about whether
> the Warehouse needs to know anything about authentication or
> authorization. I believe the answer is no.
Hugh, this is great, thank you! Things start to make much more sense now.
Some thoughts and comments:
You're welcome Dmitri, and I'm sorry the picture I gave you a couple
of weeks ago was not accurate. Our picture of how all these pieces
should integrate has gone through some major revisions in the last
month.
1) The summary also implies that there is not direct user
communication
with IWHD. So CLI should probably go to Conductor rather than directly
to IWHD. Has this been thought of/through?
You're right, Conductor should be the only path to the Warehouse I
think. The Factory is ultimately just a library, so I'm not sure it
necessarily needs access control unless it is going to write something
to the Warehouse, in which case I think that has to go through
Conductor.
2) I am afraid I do not have enough details to redo the diagrams can
you
please make a new diagram by hand and send me the picture/scan and I
will redraw it? I can take a stub and do it myself but I am not sere
this is the best.
I'll test my ascii-art skills as soon as I have the nerve :)
(seriously, expect something tomorrow).
3) I assume the catalog is just an aggregation like groups for users
so
it is going to be something close to IWHD with Conductor driving the
properties of the catalog entries and relation of the images and
catalogs to each other. Generally the more I look at it the more I think
that Katello and Conductor are in fact the only externally facing
components, all the rest should be treated as internal components of the
solution and this mutual auth and trust should be sufficient for
connections and communication. This also means that the permissions are
validated by Conductor and Katello and IWHD does not need to have its
permission model. It needs to store the permissions as metadata of the
object but there is not enforcement - it is just storage.
Yes, I think that's right.
When and how we can update and review the diagrams and move forward
on
IWHD CLI, permissions and auth/encryption topics?
So yes, I'll get a new diagram to you ASAP.
I believe we will reduce the identity/encryption piece for iteration 4
down to just shared identity. PM and the various SAs have told me they
don't think a lack of encryption is a blocker for beta, so I believe
we can put that off to the next iteration. As I've mentioned
elsewhere, the hard requirements for the solution Katello and
Conductor will share for identity are:
* Must connect natively to Active Directory with no syncing, etc.
* Must be able to set up own identity server if there is no AD
available
* Must be able to share user identity/do SSO between Katello and
Conductor
* Must not require edits to customer's DNS, etc.
Later when we get to encrypting the various endpoints, we'll need a
way to create the required certificates and so on, but that is not
going to be a concern for this iteration I don't believe.
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