Grouper Users - Open Discussion List

["Redman, Chad" <>]

I don't know if this helps your setup. What we have is that both people and 
service accounts are in LDAP. But our people are in the ou=people branch, and 
service accounts are in ou=applications. Shibboleth only looks in ou=people, 
so it doesn't authenticate service accounts. That effectively keeps them out 
of Grouper. Our WS setup goes directly against Kerberos, so works with both 
people and service accounts.

Also, if they are different subject types in Grouper, there is also a UI 
setting:

```
# comma separated source ids that the authenticating user must be in to 
authenticate (if blank accept all)
grouper.ui.authentication.sourceIds =
```

We aren't using this, but we do have different subject sources for them, so 
we could if SSO wasn't effective enough. This option is available as of UI 
2.3.0 patch 14.

And there is an analogous property for WS to limit source types too. We do 
use this just to lock it down to the sources we have the best control of.

-Chad



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

 
[mailto:]
 On Behalf Of Black, Carey M.
Sent: Friday, July 27, 2018 7: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