Thought on where to store user role information in relation to LDAP

[Trevor McKay]

Hi,

  I was thinking about user roles and where to store them.  I think it
would be nice to have the option of putting role information in LDAP for
customers that are using LDAP.

  So, that would mean optionally adding a field to whatever flavor of
user record is being used for LDAP, with a well known name.

  Thoughts on how to do this:

1) Decide on a name for role information, such as "cuminRoles", or allow
the name of the field to be set in a configuration file.

2) When authorizing external users, look in the LDAP record for
"cuminRoles"

3) If role information cannot be found, look in the cumin database (as
it does now)

4) If no role information has been found in either place, default to
"user" role

  What do you think?  Good idea? Customers that want role data in LDAP
would have to add the field to existing records (not sure how to do
that, but I am guessing it would not be too hard with a script).

  Note, the "script" mechanism could also be extended to allow retrieval
of roles.

  Users can always choose to store role information in the cumin
database, as they do now.

Best,

Trevor

[Vladimir Motoska]

Hi,

Basically I lake those thoughts but there are couple of things to
consider. 

On (09/01/12 15:03), Trevor McKay wrote:
>  Hi,
>  
>    I was thinking about user roles and where to store them.  I think it
>  would be nice to have the option of putting role information in LDAP for
>  customers that are using LDAP.
>  
>    So, that would mean optionally adding a field to whatever flavor of
>  user record is being used for LDAP, with a well known name.
>  
>    Thoughts on how to do this:
>  
>  1) Decide on a name for role information, such as "cuminRoles", or allow
>  the name of the field to be set in a configuration file. 
When speaking ldap authorization the records can be represented in
several ways in ldap tree depending on the type of directory server and
the purpose of it. 

The authorization record can be a attribute which is directly located in 
user's record. This is the most simple way. For example if we consider
something like

dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Barbara Jensen
displayName: Babs Jensen
sn: Jensen
givenName: Barbara
uid: bjensen
ou: Product Development

And assume that we have a group of "Product Development" that we want to 
assign some privileges the filter would be easy.

The second possibility is to have a group of people in ldap that we want 
to map in a user role

dn: ou=myGroup,dc=Groups,o=Top
ou: myGroup
member: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
memberUid: jdoe

It would be good to have the ability to specify the filter the searched 
attribute and some expected result...

The groups and roles are tight coupled with privileges that the group 
would have. 

>  
>  2) When authorizing external users, look in the LDAP record for
>  "cuminRoles"
>  
>  3) If role information cannot be found, look in the cumin database (as
>  it does now)
>  
>  4) If no role information has been found in either place, default to
>  "user" role
>  
>    What do you think?  Good idea? Customers that want role data in LDAP
>  would have to add the field to existing records (not sure how to do
>  that, but I am guessing it would not be too hard with a script).
>   
Do we really need the external field ? If we would use the same approach
as with the authentication we can get the list of groups that user
belongs to.

The question is how to specify the allowed actions that a specific
group/role is able to perform ? 


>    Note, the "script" mechanism could also be extended to
> allow retrieval
>  of roles.
>  
>    Users can always choose to store role information in the cumin
>  database, as they do now.
>  
>  Best,
>  
>  Trevor
>  
>   
B.R. 

Vlado


-- 
Vladimir Motoška

[Chad Roberts]

"The question is how to specify the allowed actions that a specific
group/role is able to perform ?" 

Yes, I think that is potentially the more complicated question for cumin.  In addition to
making sure that we show only appropriate elements for a given user-role, we will need to
be able to defend against URL manipulation (potentially an admin copy paste a link to a
non-admin, for whom that link needs to fail).     

Ideally, we can centralize the permission checking functionality to minimize the 
impact to the existing code/pages, but it certainly seems like there will be some
wide-sweeping changes required to get the existing pages to check the permissions at
process/render time.

Here is one vague idea (I haven't thought too much about this yet):

Maybe we can define a set of allowed views/actions for each user role (probably something
like a simple xml file).  Each widget in the cumin UI would check the permissions the
first time they are called upon in each session.  Each widget would need to essentially
need to request a permission type (with many widgets defaulting to general permissions). 
We could probably cache that result to eliminate any possible lag for later requests
although I don't think that the simple permission lookup would be that time
consuming.

Regards,
Chad

----- Original Message -----
From: "Vladimir Motoska" <motoska(a)furt.sk&gt;
To: "Trevor McKay" <tmckay(a)redhat.com&gt;
Cc: croberts(a)redhat.com, "Vladimir Motoska" <motoska(a)furt.sk&gt;, "Lukas
Slebodnik" <slebodnik(a)furt.sk&gt;, "cumin developers"
<cumin-developers(a)lists.fedorahosted.org&gt;
Sent: Tuesday, January 10, 2012 3:16:03 AM
Subject: Re: Thought on where to store user role information in relation to LDAP

Hi,

Basically I lake those thoughts but there are couple of things to
consider. 

On (09/01/12 15:03), Trevor McKay wrote:
>  Hi,
>  
>    I was thinking about user roles and where to store them.  I think it
>  would be nice to have the option of putting role information in LDAP for
>  customers that are using LDAP.
>  
>    So, that would mean optionally adding a field to whatever flavor of
>  user record is being used for LDAP, with a well known name.
>  
>    Thoughts on how to do this:
>  
>  1) Decide on a name for role information, such as "cuminRoles", or allow
>  the name of the field to be set in a configuration file. 
When speaking ldap authorization the records can be represented in
several ways in ldap tree depending on the type of directory server and
the purpose of it. 

The authorization record can be a attribute which is directly located in 
user's record. This is the most simple way. For example if we consider
something like

dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Barbara Jensen
displayName: Babs Jensen
sn: Jensen
givenName: Barbara
uid: bjensen
ou: Product Development

And assume that we have a group of "Product Development" that we want to 
assign some privileges the filter would be easy.

The second possibility is to have a group of people in ldap that we want 
to map in a user role

dn: ou=myGroup,dc=Groups,o=Top
ou: myGroup
member: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
memberUid: jdoe

It would be good to have the ability to specify the filter the searched 
attribute and some expected result...

The groups and roles are tight coupled with privileges that the group 
would have. 

>  
>  2) When authorizing external users, look in the LDAP record for
>  "cuminRoles"
>  
>  3) If role information cannot be found, look in the cumin database (as
>  it does now)
>  
>  4) If no role information has been found in either place, default to
>  "user" role
>  
>    What do you think?  Good idea? Customers that want role data in LDAP
>  would have to add the field to existing records (not sure how to do
>  that, but I am guessing it would not be too hard with a script).
>   
Do we really need the external field ? If we would use the same approach
as with the authentication we can get the list of groups that user
belongs to.

The question is how to specify the allowed actions that a specific
group/role is able to perform ? 


>    Note, the "script" mechanism could also be extended to
> allow retrieval
>  of roles.
>  
>    Users can always choose to store role information in the cumin
>  database, as they do now.
>  
>  Best,
>  
>  Trevor
>  
>   
B.R. 

Vlado


-- 
Vladimir Motoška

[Marian Zvada]

On 10.1.2012 16:28, Chad Roberts wrote:
>  "The question is how to specify the allowed actions that a
> specific
>  group/role is able to perform ?" 
a bit indirect to above, but I've got one remark in here:

I think initially we didn't want to over-complicate underlying cumin 
functionality, but as starter introduce simple "role enforcement" for 
existing actions of job manipulation which cumin already provides 
without "group(s)/role(s)" though.
I.e., I would suggest keep first focus on Hold, Release, Remove of job 
(as Lukas pointed out some time earlier cumin needs fix for this) as 
baseline of potential condor actions given by the role of authorized 
user. That would be first milestone and adding more actions would come 
later as we see how the thing move forward, including aviary approach as 
an interface that allows manipulation of condor jobs.

All other points below by Chad are indeed valid, but such a 
technicalities would be at best uncovered by systematic usage during 
development in first approximation of what we want to achieve (simple 
representation of the role in ldap user record mapped to specific condor 
action). That would also help thinking of further architectural changes 
within cumin, if needed, unless someone is already convinced in detail 
what to do.

My 2c,
Marian

>  Yes, I think that is potentially the more complicated question for
> cumin.  In addition to making sure that we show only appropriate elements for a given
> user-role, we will need to be able to defend against URL manipulation (potentially an
> admin copy paste a link to a non-admin, for whom that link needs to fail).
>
>  Ideally, we can centralize the permission checking functionality to minimize the
>  impact to the existing code/pages, but it certainly seems like there will be some
> wide-sweeping changes required to get the existing pages to check the permissions at
> process/render time.
>
>  Here is one vague idea (I haven't thought too much about this yet):
>
>  Maybe we can define a set of allowed views/actions for each user role (probably something
> like a simple xml file).  Each widget in the cumin UI would check the permissions the
> first time they are called upon in each session.  Each widget would need to essentially
> need to request a permission type (with many widgets defaulting to general permissions). 
> We could probably cache that result to eliminate any possible lag for later requests
> although I don't think that the simple permission lookup would be that time
> consuming.
>
>  Regards,
>  Chad
>
>  ----- Original Message -----
>  From: "Vladimir Motoska"<motoska(a)furt.sk>
>  To: "Trevor McKay"<tmckay(a)redhat.com>
>  Cc: croberts(a)redhat.com, "Vladimir Motoska"<motoska(a)furt.sk>, "Lukas
> Slebodnik"<slebodnik(a)furt.sk>, "cumin
> developers"<cumin-developers(a)lists.fedorahosted.org>
>  Sent: Tuesday, January 10, 2012 3:16:03 AM
>  Subject: Re: Thought on where to store user role information in relation to LDAP
>
>  Hi,
>
>  Basically I lake those thoughts but there are couple of things to
>  consider.
>
>  On (09/01/12 15:03), Trevor McKay wrote:
> > Hi,
> >
> >    I was thinking about user roles and where to store them.  I think it
> > would be nice to have the option of putting role information in LDAP for
> > customers that are using LDAP.
> >
> >    So, that would mean optionally adding a field to whatever flavor of
> > user record is being used for LDAP, with a well known name.
> >
> >    Thoughts on how to do this:
> >
> > 1) Decide on a name for role information, such as "cuminRoles", or allow
> > the name of the field to be set in a configuration file.
>
>  When speaking ldap authorization the records can be represented in
>  several ways in ldap tree depending on the type of directory server and
>  the purpose of it.
>
>  The authorization record can be a attribute which is directly located in
>  user's record. This is the most simple way. For example if we consider
>  something like
>
>  dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
>  objectClass: top
>  objectClass: person
>  objectClass: organizationalPerson
>  objectClass: inetOrgPerson
>  cn: Barbara Jensen
>  displayName: Babs Jensen
>  sn: Jensen
>  givenName: Barbara
>  uid: bjensen
>  ou: Product Development
>
>  And assume that we have a group of "Product Development" that we want to
>  assign some privileges the filter would be easy.
>
>  The second possibility is to have a group of people in ldap that we want
>  to map in a user role
>
>  dn: ou=myGroup,dc=Groups,o=Top
>  ou: myGroup
>  member: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
>  memberUid: jdoe
>
>  It would be good to have the ability to specify the filter the searched
>  attribute and some expected result...
>
>  The groups and roles are tight coupled with privileges that the group
>  would have.
>
> >
> > 2) When authorizing external users, look in the LDAP record for
> > "cuminRoles"
> >
> > 3) If role information cannot be found, look in the cumin database (as
> > it does now)
> >
> > 4) If no role information has been found in either place, default to
> > "user" role
> >
> >    What do you think?  Good idea? Customers that want role data in LDAP
> > would have to add the field to existing records (not sure how to do
> > that, but I am guessing it would not be too hard with a script).
> >
>
>  Do we really need the external field ? If we would use the same approach
>  as with the authentication we can get the list of groups that user
>  belongs to.
>
>  The question is how to specify the allowed actions that a specific
>  group/role is able to perform ?
>
>
> >    Note, the "script" mechanism could also be extended to allow retrieval
> > of roles.
> >
> >    Users can always choose to store role information in the cumin
> > database, as they do now.
> >
> > Best,
> >
> > Trevor
> >
> >
>
>  B.R.
>
>  Vlado
>
>