grouper-users - [grouper-users] Grouper and "Service accounts"
Subject: Grouper Users - Open Discussion List
- From: "Black, Carey M." <>
- To: "" <>
- Subject: [grouper-users] Grouper and "Service accounts"
- Date: Fri, 26 May 2017 17:06:02 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 184.108.40.206) smtp.mailfrom=osu.edu; internet2.edu; dkim=none (message not signed) header.d=none;internet2.edu; dmarc=pass action=none header.from=osu.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
I have been trying to wrap my head around how Grouper deals with “local subjects”. Specifically for the use case of “Service Accounts”. Specifically for WebService clients to get data from Grouper.
Note: I am not talking about how the authentication is done in this inquiry. Just how the “username”(AKA: Subject ID ?) is managed for this class of accounts.
Note: I think I am getting wrapped around “old docs” and “old term in different contexts”…..
I think I have stumbled into a confusion on my part and I am hopful that someone can answer a few questions for me.
REF: https://spaces.internet2.edu/pages/viewpage.action?pageId=14517859 ( GSH page)
I think there are two ways to make a “Local Subject” in grouper.
<![if !supportLists]>1) <![endif]>Lite UI “Create or edit groups / roles / local entities”
<![if !supportLists]>a. <![endif]>Which looks like the result from the gsh EntitySave()….. functions…
<![if !supportLists]>2) <![endif]>gsh via the “addSubject” (function?)
However, these two paths appear to result in rather different things. (Thus my confusion.)
Option 1 appears to produce an object that is visible in Grouper( via the Grouper “new” UI ). However, it uses icons/language that implies that the thing that is created is a “Group” or some other type of object than a “person”. ( The GSH output indicates this: type='application' )
Example: I created a Entity…
Entity testEntity = new EntitySave(rsess).assignCreateParentStemsIfNotExist(true).assignName("…:TEST-AGAIN").save();
subject: id='734731…..ee9b' type='application' source='grouperEntities' name='…:TEST-AGAIN'
Option 2 appears to produce an object that is NOT visible in Grouper( via the Grouper “new” UI ). However, it (the New UI) uses icons/language that implies that it is a “person”. (more like a “real subject from a Subject API”.)
Example: I “addSubject”’ed a user called “WS-TESTING” and I get this back from GSH
id='…:WS-TESTING’ type='person' source='jdbc' name='WS-TESTING”
Personally I like the idea of the service accounts being a “first class citizen” (in the Grouper UI, AKA Option 1) but I am concerned that there is some subtle thing that I am not anticipating that will make me want to have gone the other way later. Due to the type value, or some other hang up down the road.
Can any one explain why one path would be better than the other?
Can any one explain why these two paths appear to be so different?
Can anyone explain how to remove an entry that was added with “addSubject”? (Since they are not “first class objects” in the Grouper UI I have not found the “delete/remove” gsh function/code yet. It is likely “obvious” but I am not seeing it.)
- [grouper-users] Grouper and "Service accounts", Black, Carey M., 05/26/2017
- [grouper-users] RE: Grouper and "Service accounts", Hyzer, Chris, 05/27/2017
Archive powered by MHonArc 2.6.19.