Charles Severance to Graham
I incorrectly assumed that you were doing a course-style integration so I gave the answer course style - Sakai is not even close to being a course management system at its core - it is a general purpose collaboration system that 80% of the folks are using Sakai to teach - so I just assumed mistakenly that you were working on this course style because so many do - Glenn made the same mistake as well.
In research, often things are quite different. We almost have to start the conversation over.
How Sakai works does not change - how we talk about it needs to change so we can get to understanding more quickly.
There are really three things:
Who are you? Authentication - that is easy.
What groups are you in?
What roles do you have in those groups?
The main question is which of those three elements do you want to store inside of Sakai and which ones come from the outside world? Be aware that it is OK in Sakai to answer "yes" to both.
The simple solution is to use Shib only for authentication. Trivial and simple - people add each other to groups inside of Sakai and give them roles - perhaps they even invent brand new roles like - "lead investigator" or "reviewer" in addition to the Sakai-provides roles "maintain" and "access". This works pretty well and is used in 99.9% of the research applications of Sakai - too easy - not much fun - especially for a Shib-Ninja.
Remembering that hybrid is possible - here is one possible use case scenario that I have been thinking of for a while - you are making a Sakai site for a bunch of physicists. There are three broad groups that are known to Shib and maintained in Shib and each person who is in a group gets an attribute which indicates both member of and role within said group. These groups are used across many applications - not just Sakai.
Say, the groups are "everyone", "management", and "developers" and the roles are "maintain" and "access" where maintain can mess with stuff and access has less power. Then the attributes might be "everyone.access", "everyone.maintain", "management.maintain" and "management.access" ...
You set up Sakai using Shib as auth and let your users go crazy making sites and managing groups within Sakai - these "organically grown" sites do not have an "external ID" associated with them - they are purely maintained inside of Sakai - "external ID" in Sakai is the clue indicating that Sakai must consult the providers. Not all sites have external ids - as a matter of fact for project sites - the default is not to have an external ID.
Then you make three sites in Sakai called "everyone", "management" and "dev" and set their External IDs to "everyone", "management", and "dev" respectively - now when things happen in these sites, the providers get called. We end up with a problem where the provider cannot get the entire list of people "a-priori" so when the admin goes in - the roster is incomplete - we solve this in a bit. But here is the way things get populated.
When user bob logs in, Sakai goes through all sites that have an external ID (this is what Sakai does normally) and make sure to check to make sure that bob is properly enrolled in those sites with external IDs - so the provider is called on all three sites everyone, management, and dev within the content of bob asking the question - "what is bob's role in site dev"? The provider can look at the attributes (we cleverly named the external ID the same as the attribute prefix) and viola the provider tells Sakai bob's roles in all three of the groups - now that role and membership is stored inside of Sakai so the roster looks good - at least for bob and Sakai's AuthZ looks good and works peachy - at least bob is in the roster.
Bob stays in the roster stored in Sakai until bob logs in again and Shib no longer contains the attribute everyone.maintain for bob. Sakai immediately (before login completes) removes bob from the membership and role from the everyone site. So bob cannot ever log in and see a site that Shib will not assert the attribute for. Bob always sees a consistent universe.
So we populate rosters in a lazy fashion as people log in. Other than admin folks looking at the rosters and finding them incomplete - the user experience is perfect - since each time you log in, Sakai internal structures are synchronized with Shib for those sites with External IDs - it works pretty swell.
If you want Shib to be the only source of membership in every Sakai site - I wonder why? It means that you need to build a very agile way to make form and maintain groups in Shib that is as slick, user friendly and agile as Sakai. The absolute awesome beauty of Sakai is the ease with which researchers can make new groups for whatever ad hoc collaboration they need with a few clicks. I have some ideas for how these Organic groups can produce Shib attributes for other applications - but that is for another time - perhaps with a beer, pen and a napkin in late September.