Grouper Developers Forum

[dan <>]

Ahh, I see. So the policy information is reflected at the level of each subject in question, and not coalesced for each user depending on their memberships.

This is good to know. Thanks!

D

On 1/24/07, Tom Barton <> wrote:

Grouper and Signet manage policy-related information. They do not act as
Policy Decision Points or Policy Enforcement Points. A PDP is where your
questions are answered. This is often realized as access control
expressions forming part of the application's configuration, but many
run-time access management architectures are in use.

So I'm simply saying it's up to your apps to decide how they will use
the group and permission information presented to them.

dan wrote:
> Ahh, excellent, this is really useful. Thank you.
>
> Another question, while I've got everyone's attention ;-) Say I've got
> a high-level group, called "Everyone", which has a permission "cannot
> publish photos".
>
> Then I create a sub-group called "Photographers", which has a
> permission "CAN publish photos", and another grouper called "Terrible
> Photographers", which has the permission "CANNNOT publish photos".
>
> If someone was a member of both those last two groups, would they be
> able to publish photos or not?
>
> What if I set a flag on the user saying specifically that they could -
> does that override all group permissions?
>
> I guess I'm saying "What's the precedence of permissions?"
>
> (I would check this myself, but I'm still getting everything up and
> running, and it would be nice to have an answer on this today)
>
> Thanks,
> Dan
>
> On 1/24/07, Tom Barton <> wrote:
>>
>>
>> dan wrote:
>> > Which reminds me - how do you usually push your group and privilege
>> > information out to other applications? Say you've got a mail app that
>> > needs groups, and reads those groups from its own text file format, or
>> > a photo sharing application which needs to know if a user has a
>> > "publish" privilege. How does one model those scenarios in the
>> > Grouper/Signet universe?
>>
>> You're probably aware that there is a new LDAP provisioning connector
>> that pushes groups, memberships, and permissions to LDAP directories.
>> For other integration scenarios you currently need to provide your own
>> tools. Grouper 1.1 provides java API and command line interfaces, and an
>> XML export tool to source group and membership info into your
>> integration infrastructure. Signet 1.0.1 provides a java API for this
>> purpose. Lynn or Dave might comment on additional integration
>> capabilities in Signet 1.2, to be released soon. In the roadmap for both
>> products is further tooling to source changes to groups, memberships,
>> and permissions (so that your integration tools don't need to compute a
>> logical diff) and SOAP interfaces. For a quick start right now though,
>> you might want to consider repurposing the portions of the LDAP
>> provisioning connector that face grouper and signet, swapping out the
>> LDAP facing stuff for whatever suits.
>>
>> Two particular management capabilities seem apropos of your scenarios.
>> First, and most generally, you can assign a permission to a group, which
>> might, for example, determine who has a publish privilege for your photo
>> sharing application. Secondly, and more specific to particular cases,
>> you can add custom attributes and lists to groups which are meaningful
>> to your provisioning processor or to the provisioned application. This
>> might be useful for groups being used for mail lists, for example.
>>
>> > Please excuse my general ignorance of the field, this is quite new
>> to me.
>>
>> Not at all. It's pretty early in the adoption curve for this type of
>> access management.
>>
>> Tom
>>