[katello-devel] [foreman-dev] Signo and shared user management

[Justin Sherrill]

On 07/01/2013 07:56 AM, Ivan Necas wrote:
>
> ----- Original Message -----
>> On Thu, Jun 20, 2013 at 05:32:32AM -0400, Ivan Necas wrote:
>>> 3) since we have signo already here for SSO, it seems like good fit
>>>    for other user-related actions. How it could work:
>>>
>>>    a. in Signo, we define the users (or connect it to LDAP), and assign
>>>    roles to them (optionally mapped to LDAP groups). Signo itself wouldn't
>>>    know what permissions the roles have. So in signo, there would be
>>>    something like
>>>
>>>    user  | contexts | roles
>>>    ---------------------------------------------
>>>    admin |          | admin
>>>    peter | ACME     | content_management
>>>    marry | EMEA     | provision
>>>    john  |          | content_management,provision
>>>
>>>    b. In Katello/Foreman, instead of mapping the subsystem roles to users
>>>    directly,
>>>       the Katello/Foreman roles would be mapped to the Signo roles (ideally
>>>       1:1).
>>>       so for example, for content_management Signo role, a role in Katello
>>>       would exist allowing changesets
>>>       provisioning. In Foreman, the content_management would be mapped to
>>>       role allowing
>>>       creation of new environments.
>>>
>>>    c. Today, when user logs in into Katello, Katello looks at it's roles and
>>>    determines
>>>       the permissions based on that.
>>>
>>>       With this change, when user logs in, Katello asks signo what Signo
>>>       roles the user
>>>       has (similarly to LDAP groups today), and uses the mapping between
>>>       Signo roles and Katello
>>>       roles. From the Katello roles, it determines what he/she can/can't do.
>>>
>>>    So in short: user <-> roles mapping happens in Signo, roles <->
>>>    permissions mapping
>>>    happens in the Katello/Foreman.
>>>
>>>    The task for the integration would be to pre-define the roles in Signo
>>>    and mapping
>>>    to permissions in Katello and Foreman, so that if someone has some role
>>>    in Signo,
>>>    it will let him/her do all the things in the subsystems, that this role
>>>    requires.
>> If I understand the table above correctly, the user is the subject,
>> the contexts is the object, and roles is the operation that subjects
>> can do with objects. Are you sure that objects modelled this way will
>> not limit you ery soon. The example shows ACME and EMEA which I assume
>> are organizations ... but soon you might want environments or systems
>> or system groups or repos as objects. To store that relationship, you
>> would have to know about those types of objects in Signo and in LDAP.
>> Do you really have two-way synchronization of data in mind?
> I was thinking about Signo/LDAP saying what roles does the user have and
> Katello/Foreman determining the access to the subjects based on the data.
>
> For the other entities acting as object, what about roles in Signo/LDAP such
> as 'systems_self_service' meaning the user can only see his/her systems? The
> information about what 'owning a system' means would be still in Katello/Foreman.
>
> We could also make the meaning of ACME/EMEA more general, saying it means groups of users.
> In subsystems, we would then assign this groups to permissions. Katello/Foreman
> would say what groups are available in Signo. Signo would say what users as in those groups.
> It's not two-way syncing, as this are two separate operations (provided Katello doesn't store
> the info about users <-> roles association and one can't CRUD groups in Signo (just assigning
> them to users).
>
>
> -- Ivan

So to me it feels like a 'requirement' that system visibility be the 
same across both systems.  If we implement the logic of what systems are 
visible in two places without any real coordination, it seems like it 
could be vastly different.  Heck, even if we do implement it with 
coordination they could be vastly different.

Today katello defines  read and/or write access to systems in a few ways:

System Group
Environment
Organization


and I feel like all three levels are appropriate.  The system group case 
would be somewhat tricky for foreman to cover given that it has no 
notion of our system groups currently IIRC.



-Justin
>
>> --
>> Jan Pazdziora
>> Principal Software Engineer, Identity Management Engineering, Red Hat
>>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel