Grouper Users - Open Discussion List

["Redman, Chad" <>]

Your post made me realize that even under the same Tomcat instance, they are 
still different containers. So you could add groups.wheel.readonly.use=true 
to grouper.properties in the WS deployment but not the UI deployment.

-Chad


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of O'Dowd, Josh
Sent: Friday, July 27, 2018 9:47 AM
To: Black, Carey M. 
<>;
 Hyzer, Chris 
<>
Cc: 
;
 Robinson, Justin S 
<>
Subject: RE: [grouper-users] web service user READ only, ALL groups

Carey,

Our UI and WS both run under a single tomcat instance.  We authn using 
Shibboleth SP/IdP for UI, and tomcat still authn WS requests so we do have 
"WS system user" accounts in our tomcat-users.xml.  So if I use Chris's 
suggestion, I am really getting what you are suggesting, as well, simply by 
placing the WS user(s) into the grouper that I want to give 
wheel.readonly.use to, if I am understanding him correctly.

-Josh

_______________________________________
From: Black, Carey M. 
[]
Sent: Friday, July 27, 2018 5:34 AM
To: Hyzer, Chris
Cc: 
;
 O'Dowd, Josh; Robinson, Justin S
Subject: RE: [grouper-users] web service user READ only, ALL groups

Chris,

What if that requirement was desired ONLY in the Web Services interface?....
But I also guess it might also depend on the Authentication source(s) used 
for the UI vs  WS too.....
        I tend to think of "non-human" accounts using WebServices (WS) and 
humans using the UI.

Could an installation use two tomcat instances. ( one for the UI and a 
separate one for WS )
        ( Which you really should do anyways. )
Then the UI could not use that setting.
And the WebServices instanced could.


That way WebServices users could "enjoy" that setting only via the WS calls 
and not exposing it to "UI users"?

Just a thought...

--
Carey Matthew 



-----Original Message-----
From: 

 
<>
 On Behalf Of Hyzer, Chris
Sent: Friday, July 27, 2018 2:27 AM
To: O'Dowd, Josh 
<>;
 Robinson, Justin S 
<>
Cc: 

Subject: RE: [grouper-users] web service user READ only, ALL groups

There is a way to do a global READ or VIEW or whatever priv without the 
overhead of the inherited privs copying to every object:

(from grouper.base.properties)

# A readonly wheel group allows you to enable non-GrouperSystem subjects to 
act
# like a root user when reading the registry.
groups.wheel.readonly.use                      = false

# Set to the name of the group you want to treat as the readonly wheel group.
# The members of this group will be treated as root-like users when reading 
objects.
groups.wheel.readonly.group                    = 
$$grouper.rootStemForBuiltinObjects$$:sysadminReadersGroup

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of O'Dowd, Josh
Sent: Thursday, July 26, 2018 1:01 PM
To: Robinson, Justin S 
<>
Cc: 

Subject: Re: [grouper-users] web service user READ only, ALL groups

Thanks for that Justin.  I will give that a shot once I understand what its 
doing, exactly.  But your example gives me points of reference to learn more 
about.  Very kind.

Thank You!
-Josh

On Jul 26, 2018, at 10:55 AM, Robinson, Justin S 
<<mailto:>>
 wrote:

Hi Josh,

There are probably other (possibly better) ways to achieve this - but one way 
is to use the RuleApi and GSH to inherit privileges. The example below should 
do it:

grouperSession = GrouperSession.startRootSession();
someStem = StemFinder.findByName(grouperSession, "stem:path");
webServiceClientUsers = GroupFinder.findByName(grouperSession, 
"etc:webServiceClientUser");
RuleApi.inheritGroupPrivileges(SubjectFinder.findRootSubject(), someStem, 
Stem.Scope.SUB, webServiceClientUsers.toSubject(), 
Privilege.getInstances("read"));
RuleApi.runRulesForOwner(someStem);

Thanks,

Justin Robinson
Indiana University

On Jul 26, 2018, at 12:42 PM, O'Dowd, Josh 
<<'>>
 wrote:

Hi,

I am wondering if it is possible to give an etc:webServiceClientUsers group 
member READ(not ADMIN) privilege for ALL groups(including any new), instead 
of having to add that privilege to each group individually?  More of a global 
group READ privilege, similar to what the etc:sysadmingroup has with the 
ADMIN priv for all groups is what we are looking for.

Any help is much appreciated.

Thanks.
-Josh O'Dowd
University of Montana