Grouper Developers Forum

["Michael P. Pelikan" <>]

Very interesting post. Thanks,
-- Michael

On 8/11/11 12:03 AM, 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

--
Michael P. Pelikan
Emerging Technologies Group
Information Technology Services
The Pennsylvania State University