Grouper Developers Forum

[LLG5 <>]

Penn State has the same use case.

 

The  Central Person Registry (CPR) that Penn State is developing needs to control access to and/or update of certain data fields in the CPR.    Initially the permission model was developed internal to the CPR but we would like to move the management into Grouper.

Lynn

On Aug 15, 2011, at 11:10 AM, Chris Hyzer wrote:

Yes, I would like to do oracle security with Grouper at Penn, the example is the use case.  Penn State actually has the same use case, though Im not 100% sure Grouper will be used, maybe we will see how it goes at Penn J

 

Thanks,

Chris

 

From: Tom Barton [mailto:] 
Sent: Monday, August 15, 2011 10:44 AM
To: Chris Hyzer
Cc: 
Subject: Re: [grouper-dev] RE: grouper subject attribute security

 

Do you (Chris, or anyone else) have a specific use case that is motivating your thought here? I'd like to be sure we're alll thinking about roughly the same thing.

Tom

On 8/15/2011 8:18 AM, Chris Hyzer wrote:

No, the schema is not in a subject source on its own, and it is impossible for a non-grouper-admin to add it to one, that is one of the problems.  If it is an entity type of group, then since groups are subjects, then it would appear in the g:gsa subject source…

 

From:  [] On Behalf Of Tom Barton
Sent: Sunday, August 14, 2011 11:32 PM
To: 
Subject: Re: [grouper-dev] RE: grouper subject attribute security

 

If I understand correctly, the schema is associated with a security principal on the one hand, and with an entity on the other. Is this entity also a subject? Provided through grouper subject adapter?

Tom

On 8/10/2011 11:03 PM, Chris Hyzer wrote:

Another piece of this use case is a common issue for people: custom subjects.  Note, this discussion is obviously not for 2.0.  I want the client to be able to create a subject on the fly that represents a schema that has access to a resource.   Then I want to assign permissions for that schema to be able to read rows/columns in the database.  We have discussed this before, and have agreed that this is needed, but if we went from scratch, it would be too much work, lots more important stuff to do.  Here is a tweak that can make it work.

 

Right now the grouper_groups table holds two types of objects, groups and roles.  I think we should add another type: entity.  Here are the differences:

 

Group: holds subjects

Role: holds subjects and rbac permissions

Entity: doesn’t hold subjects or role permissions (of course it is a subject, so if it were added to a role you could assign individual permissions in the context of the role)

 

The work involved:

 

1.       Add an enum value to TypeOfGroup

2.       Restrict in the API that this type cannot add/remove members to itself, or assign update/read/optin/optout privileges

3.       In the UI picklists, it should not show up in the group comboboxes etc.  The icon on the screens should look like an entity and not a group

 

The result:

 

1.       If you can CREATE in a folder, you can create entities in that folder (e.g. the extension would be the schema name in this case, or we could add a custom attribute or something.  This is distributed/delegated, and the WS operations already exist

2.       You could assign that entity to a role, and assign permissions to it (i.e. that schema can read specific rows/cols)

3.       You could assign VIEW and ADMIN privileges to it so other Grouper users do not need to be bothered with it (the major disadvantage to having this in a custom subject source which makes it public, and hard to namespace)

4.       There are no schema changes, all the import/export, WS, auditing, PIT, notifications, etc will work

 

Note, you could do this now (create groups to represent subjects), and it is probably the best way without requiring a lot of work, but it would look weird in the UI, and you would have to remember to not add members instead of being constrained if you try…

 

Thoughts?  J

 

Thanks,

Chris

 

 

From: Chris Hyzer 
Sent: Tuesday, July 26, 2011 3:16 PM
To: 'Grouper Dev'
Subject: grouper subject attribute security

 

At Penn we are developing similar to what Penn State is working on, user attribute security with SQL data views.  i.e. users (subjects ) have a lot of attributes in our IdM, and we want to preprocess them, and have them available for consumers.  E.g. the various names, emails, affiliations, some source-specific data (title/major), etc.  We have 130 columns in the data view.  These need to be secure at a column and row level (e.g. an application could get access to see employee data, but not student data, and only certain columns e.g. not ssn).  Therefore this is not really conducive to our LDAP deployment.  Right now we are planning on a SQL implementation using Oracle VPD/FGAC.  The permissions will be modeled as Grouper permissions and provisioned into security tables for VPD/FGAC to use.

 

We have a handful of Grouper sources.xml subject attributes available (name, email, netId, etc).  However, I think it would be nice if these extra attributes could be available in the Grouper getSubject (only) web service.  This is optional, and would be dynamic, and protected by Grouper permissions.  This is a very minor tweak, it would be is a Java interface where you could write code to match up the request, and the authenticated subject, and get the data for the response based on security.  Grouper would not store or manage these attributes, just like it is now.  I know Grouper is not an IdM, but I think optional plugins where gaps in institutions’ IdM exist could be useful.  The next step (don’t need this now, but we can discuss later) could be to extend this to the sources.xml subject attributes so that those can be managed a little more closely across the other Grouper operations (getMembers)…

 

What do you think?  J

 

Thanks,

Chris