KH Last Steps Checklist - May 2013

Light review of completed documentation pages

The following need *light* review from you -- these are not very different from your drafts, so really just a quickie:

Shibboleth SP Installation and Configuration for Bamboo Trust Federation Clients
Maintaining SAML Metadata that establishes a Trust Federation

Moderate review of completed documentation pages

The following needs *moderate* review, in light of my decision to move the population of subjects detail to the Grouper Install - Configure - Populate document. Most important questions:

==> does overview make sense?
==> does the contextualizing bit and link in the final section re: BPID subjects make sense?

Maintaining Application Catalog Data for Trusted Clients

Grouper Install - Configure - Populate Documentation Page

Grouper Install - Configure - Populate

Grouper Install - Configure - Populate, we've agreed, needs some more filling out.

(a) There's a list in a prior e-mail and also in a 30 April 2013 comment to your draft page Populating a Bamboo Grouper Instance, laying those out

(b) We'll need to include DDL for instantiating the bbsubjectdb database (interim Subject Authority) in Grouper -- console output on how to create db (which I have, actually, from the import documentation) and how to populate its table(s), etc.

Grouper Privilege Types and Names

On the Grouper Service API page:

(a) Privilege types and names

There are two recipes around delegation of privileges: one for groups, one for stems. Well and good. But these and the REST method documentation further down the page do not give lists of accepted / acceptable values for the parameters "privilegetype" and "privilegename" ... and in my (admittedly brief, but not shallow) dive into the Grouper docs, I'm seeing methods by which a list of available values can be obtained but not any documentation describing them.

Grouper Recipe for group membership as factor in access policy for a resource

(b) Recipe for "Use Group membership to govern access to a specific resource"

On the Grouper Service API page:

I think we were not on the same page re: what this means. What I intended this recipe to be about was how one would use a group in a policy decision. For example, if I created a resource "A" which, by default, I own and control; and want to extend access to the resource to "My Group," how would I do that.

I believe the answer to that question lies in the Protected Resource Service API. Not your responsibility to come up with a recipe for that. Does this make sense to you?

[Going a bit further, FYI and to record my lingering problem with this: the Protected Resource Service API does not give any examples that extend privileges to a group. Examples Fernando wrote into the API involve extending privileges to persons and roles. I'm weighing whether to write him a note asking for guidance, or trying to figure out the proper invocation myself before writing him a note to ask whether I'm getting it right. Yeesh.... UPDATE: after correspondence with FA, PR Service API includes examples for using GROUP in a POLICY decision ~SJM.]

Documentation plus PoC or Coding

Social/SAML Gateway

Social/SAML GW

Social/SAML Gateway to enable social media identity provision

Per prior correspondence and a comment thread tracked on KeithH Documentation Pages (about 3/4 of the way down), we've agreed there's some more work here, and agreed that it will have to come in later than the other docs due to various factors. It would be helpful to have Keith's guesstimated target date for this work, but it's understood that this is probably just an approximation.

Subject Adapter (Grouper - Person Service integration)

Subject Adapter

This isn't documentation, but I thought I'd tack it on at the end so we don't forget....