Grouper Developers Forum

[Tom Barton <>]

So, to refine your idea a bit, would you propose that grouper ship with a predefined "service" attribute definition for which attribute assignment objects, one per service, can be created by deployers to use as tags?

Also, I wonder about the focus. I've taken your "domain" and scoped it down to "service" to relate its use to a somewhat narrow purpose. Of course, other purposes might be served by a tagging approach. But I'm thinking that it'd be best to have separate tag schemes for separate purposes rather than a single very general one, where the different purposes can only be recognized by convention in the tag strings themselves.

Tom

On 8/15/2011 8:16 AM, Chris Hyzer wrote:

The tags are in the namespace, and are multi-assignable (one group could apply to multiple applications)… The side effects are how the UI treats them (however we decide that to be), so it is up to the application of which groups to include or how many domains they would have for the application(s).  Thanks for the response!

 

Chris

 

 

From: [] On Behalf Of Tom Barton
Sent: Sunday, August 14, 2011 8:01 PM
To:
Subject: Re: [grouper-dev] RE: domain added to roadmap?

 

Chris,

These days many IT shops either have a service catalog (ala ITIL), are busy about building one, or wonder when they should start the work of doing so. With that notion of "service", I really like the idea of identifying which service(s) a given group supports, and vice-versa. However, I wonder about several things with this approach to that objective.

1. How deep into indirect (and factor) membership should that identification go? For example, referring to my grouper intro slides (https://wiki.jasig.org/download/attachments/45450793/201105-grouper-intro.pdf?version=1&modificationDate=1306173769191), on slide 13 there's a depiction of a bunch of groups that are involved in managing access to a vpn service. Some have positive impact, others negative, some are specific to this service, others pertain to several services (though that's not depicted in slide 13).

2. We might not need to resolve the complication of Q1 above in order to tell if subject X is supposed to have access to service Y, right now. But that may depend on how grouper is being used to manage access to a service. If there is a single group whose members are those that have that access (as in the vpn:authorized group on slide 13), then all we need to do is identify that single group with the "vpn" service. But some services may perform their own equivalent of grouper's boolean calculations and not leave that to grouper. Would we include such a service in this solution, or would we mark all of the groups referred to by that service? I suppose we'd just have to tell the user "well, we can't tell if you're allowed to access service Y or not".

3. Should services be tags, or should they be objects in a grouper namespace? We've spoken before of mapping "resources" to namespaced objects. Services seem like a useful and fairly simple, high level starting point, perhaps leading eventually to more granular types of resources as an org's access management practices mature.

Tom

On 8/9/2011 2:12 PM, Chris Hyzer wrote:

Two side effects of this…

 

1.       You can list all the applications that use the authorization system (service registry).

2.       A person can go and see what applications they have access to… maybe we could have links to the start page of the apps too…

 

Thanks,

Chris

 

From: Chris Hyzer
Sent: Thursday, August 04, 2011 12:32 AM
To: 'Grouper Dev'
Subject: domain added to roadmap?

 

I think it would be useful for Grouper to have a “domain” tag which could be attached to groups/permissions/etc or used in configs etc.  The domain would be similar to an application or a group of applications. 

 

The end result is that someone could be linked to the UI with the domain in the URL, and they would see the groups/folders/permissions/instructions/etc that are relevant to that domain.  Or in the WS, the client could request memberships for a user relevant to a domain, and if groups/roles/permissions were added after the application was coded, they would be return based on domain.  Maybe it would also filter the subjects returned in subject searches.  E.g. an application that has nothing to do with prospective students or alumni should not return those subjects in subject searches.

 

Note that it is currently a type of attribute definition: domain.  Currently it is not used, but I picture it being a marker attribute with no value, perhaps with restrictions on which types of objects it can be assigned to: group/role, folder, attributeDef/permissionDef…  and like limits there are other configs or rules that are used for domains…

 

If you are interested in this, or have other ideas about it, let us know.

 

Thanks,

Chris