Grouper Users - Open Discussion List

[Chris Hyzer <>]

I just updated the GSH page with another example of generating GSH from SQL.  I did one for oracle, though you could see how it works and do a similar thing for SQL server:

 

https://spaces.internet2.edu/display/Grouper/GrouperShell+%28gsh%29

 

Here is an example of removing privileges from a user on groups in oracle

set linesize 1000;

set pagesize 1000;

select 'revokePriv("' || gmlv.group_name || '", "' || gmlv.subject_id || '", AccessPrivilege.' ||

case

when gmlv.LIST_NAME = 'admins' then 'ADMIN'

when gmlv.LIST_NAME = 'readers' then 'READ'

when gmlv.LIST_NAME = 'viewers' then 'VIEW'

when gmlv.LIST_NAME = 'updaters' then 'UPDATE'

when gmlv.LIST_NAME = 'optins' then 'OPTIN'

when gmlv.LIST_NAME = 'optouts' then 'OPTOUT'

else gmlv.LIST_NAME

end  || ');'

  as script

from grouper_memberships_lw_v gmlv where subject_id = '12345678' and GMLV.LIST_TYPE = 'access'

 

 

Note: the subjectId would be GrouperAll (see in grouper_members table), then take the generated script (a bunch of revokePriv(); GSH commands), review it, put it in a file next to gsh.sh, and run: ./gsh.sh filename.gsh

 

Note: if the case part is a problem, you could do 6 scripts for each priv type, or two if you only care about readers and viewers…

 

Ok?

 

Thanks,

Chris

 

 

From: Klug, Lawrence [mailto:]
Sent: Wednesday, May 23, 2012 4:03 PM
To: Chris Hyzer;
Subject: RE: Folder visibility

 

Hi Chris,

 

I see – yes, some of these groups were in place before I changed the default.  We are using SQLServer 2008 here.  Interested in what you have in mind.

 

Thanks,

 

Lawrence

 

From: Chris Hyzer []
Sent: Wednesday, May 23, 2012 12:14 PM
To: Klug, Lawrence;
Subject: RE: Folder visibility

 

Well, it’s the global “default”, but not the global setting.  So if you create a new group, it wont have those settings, but existing groups would since they were created when that setting existed…  Do you want to remove everyentity read/view from all groups?  We could easily do that with SQL generating a GSH script if you like… which DB do you use?

 

Thanks,

Chris

 

 

From: Klug, Lawrence
Sent: Wednesday, May 23, 2012 2:42 PM
To: Klug, Lawrence; Chris Hyzer;
Subject: RE: Folder visibility

 

Hi Chris,

 

Do the properties file settings affect “EveryEntity” privileges?

 

I modified grouper.properties as described in the thread below:

 

groups.create.grant.all.read          = false

groups.create.grant.all.view          = false

 

Then deployed the UI to a test server.  Observe that “EveyEntity” still has READ and VIEW privileges (see screen grab).

 

Is this the expected behavior?

 

Thanks,

 

Lawrence

 

From: [] On Behalf Of Klug, Lawrence
Sent: Monday, May 21, 2012 10:18 AM
To: Chris Hyzer;
Subject: [grouper-users] RE: Folder visibility

 

Chris,

 

Thanks for the ideas.  This may be enough to accomplish our use cases.

 

Cheers,

 

Lawrence

 

From: Chris Hyzer
Sent: Monday, May 21, 2012 9:40 AM
To: Klug, Lawrence;
Subject: RE: Folder visibility

 

Did you try this in the UI, or are you asking us to try it?  J

 

First of all you should probably set these in the grouper.properties:

 

groups.create.grant.all.read          = false

groups.create.grant.all.view          = false

 

 

My guesses are:

 

1.       When Joe logs in, he will start at root, but he will see the Math Lab folder (if it is a top level folder), or if he clicks “manage” or “create” on the left he will see the folders where he has those privileges.  He could also bookmark the folder URL to start there each time

2.       He shouldn’t be able to see other folders where he doesn’t have objects inside that are relevant to him

3.       Grant READ on the org group to someone who needs it and they will only see that group/folder and not others

 

Let me know if you need me to do an example or if you can try it and let me know what doesn’t work.

 

Thanks,

Chris

 

 

From: Klug, Lawrence
Sent: Monday, May 21, 2012 11:18 AM
To: Chris Hyzer;
Subject: RE: Folder visibility

 

Here are a couple of use cases we are thinking about.

 

Is it possible to set up Grouper UI so that on login, the user lands on folder down the hierarchy?

 

First use case:

1.      We assign a folder “Math Lab” to the Math Department and grant folder/group create permissions for the “Math Lab” folder to the Math Department Admin. “Joe.”

2.      When Joe logs in to Grouper – he lands on the “Math Lab”  folder and begins creating folders and groups.

3.      Joe can’t see any of the folders/groups above the “Math Lab” folder.

 

Is it possible to control folder visibility?

 

Second Use case:

 

4.      Orgs hierarchy has been imported via Grouper loader group into a parallel  “UCLA:Orgs” stem

5.      Joe doesn’t want to re-create the whole math department group so he asks for access to the Org stem

6.      We assign view/read rights for the Math dept org to Joe

7.      Joe is able to view the Math dept org and add memberships to his groups created in “Math Lab” folder

8.      Joe can’t see other folders in the org hierarchy that are outside the Math department.

 

 

From: [] On Behalf Of Klug, Lawrence
Sent: Thursday, May 17, 2012 1:19 PM
To: Chris Hyzer; Nathan Kopp;
Subject: [grouper-users] RE: Folder visibility

 

Chris,

 

Yes, I’ll work up a use case for this.

 

Thanks,

 

Lawrence

 

 

From: Chris Hyzer
Sent: Thursday, May 17, 2012 11:59 AM
To: Nathan Kopp; Klug, Lawrence;
Subject: RE: Folder visibility

 

You can do a similar thing with rules… J

 

https://spaces.internet2.edu/display/Grouper/Grouper+rules+use+case+-+Inherited+privileges+on+groups

 

Hope a new UI at some point will make that easier to assign/view/etc.

 

Lawrence, can you do a use case about how grouper works now to show us what you are concerned about?  i.e. go to the UI as a non privileged user and see what they can see which is not ideal?

 

Thanks,

Chris

 

From: Nathan Kopp
Sent: Thursday, May 17, 2012 2:53 PM
To: Klug, Lawrence; Chris Hyzer;
Subject: RE: Folder visibility

 

I’m not sure if this is exactly what Lawrence is asking, but I’ve always thought it would be great to be able to assign group permissions (e.g. “update” to let you manage members) at the FOLDER level and have those permissions apply to all groups stored within that folder.  That would make life much easier for certain use cases.

 

-Nathan

 

From: [] On Behalf Of Klug, Lawrence
Sent: Thursday, May 17, 2012 1:47 PM
To: Chris Hyzer;
Subject: [grouper-users] RE: Folder visibility

 

Chris,

 

I’m imagining a scenario where the organizational hierarchy has been loaded into grouper with many levels of folders and groups (divisions, sub-divisions, departments, etc.).  Let’s say we create a folder in a different  area for the Math Department and give them admin control of the folder.  They may want to work with groups in the organizational hierarchy related to Math, but might need to  be restricted from other sections of the orgs.  Can we limit visibility? How do you handle this at Penn?

 

Thanks,

 

Lawrence

 

 

From: Chris Hyzer []
Sent: Thursday, May 17, 2012 10:26 AM
To: Klug, Lawrence;
Subject: RE: Folder visibility

 

Well, there is no VIEW privilege on folders, so I don’t think the API hides them.

However, the UI should not show folders that are not applicable to a user (e.g. no privileges and no objects inside which are viewable or have privileges).  Right?  Or does it show them somewhere?

There is a find folder WS operation, maybe that should be locked down in a similar fashion if it is not already.

 

Thanks,

Chris

 

From: On Behalf Of Klug, Lawrence
Sent: Thursday, May 17, 2012 1:20 PM
To:
Subject: [grouper-users] Folder visibility

 

I have a question about folder visibility in Grouper.  Are all folders other than root:etc visible by default to non-sysadmingroup members?  Is this configurable?

 

Thanks,

 

Lawrence Klug

IMS Platform Development

310 825-2061

ext 52061