Groups and Permissions

GaPs is "Groups and Permissions". It exists as a general framework embedded in uPortal 2 and, separately, as a standalone project that is used in uPortal 3. It is likely that uPortal 2 will evolve to drop its embedded GAPs code and instead use the externalized GaP. They are very similar.

http://www.ja-sig.org/wiki/display/GAP/Home

PAGS ("Person Attribute Group Store") is just one group store implementation that plugs into GaPS. Person Attribute Groups are clever just-in-time groups that are defined by logical expressions on user attributes. (A Group "Class of 2004" could be defined as all users such that their classYear user attribute is "2004"). This allows you to leverage user attribute stores such as LDAP to define groups for use in the portal.

Other currently implemented group stores include the uPortal database group store and a couple LDAP group stores.

In theory one could write a Sakai Group store that is backed by Sakai web services and exposes Sakai course affiliations as groups.

Group stores can be manageable via the portal (read/write) or not (read-only). They can be enumerable (e.g., a database backed group store) or not (in PAGS I can only ask the system what groups a given user is in; I can't ask it for all members of some particular PAGS group).

For instance, plausibly a Sakai group store would be externally managed (read-only) and enumerable.

Permissions are distinct from groups but use groups. Roles are not a separate data structure, but it is a typical practice to create a group for a role.

Permissions take the form of is allowed to on . E.g., Students are allowed to Subscribe to the Campus News Channel. Various modules can register permissions to be managed by the Permissions Manager. When you create an announcements topic in the Columbia Announcements Channel, this brings into existence permissions for who can create announcements in the topic, delete announcements, etc. Zero or more Groups (and/or individuals) can be granted each of these permissions.

There is a hierarchy and inheritance scheme for permissions; I'm not prepared to speak to it authoritatively off-hand. It's fair to say that it's less well-understood than it should be.

Dan Ellentuck is the authority and primary developer of uPortal / standalone GAPS. He has been working to take the "standalone" GAPS to releasable state. uP3 developers have been pitching in, particularly to use this in uP3 and develop uP3 UI around it.

"Standalone" needs to be in quotes because while GAPS becomes a standalone library with this refactoring, it does not provide its own UI. Both uPortal 2 and 3 provide UIs for administering portions of GAPs. (Other portions use file-driven configuration).

I hope these notes prove helpful. Dan Ellentuck is really the person to approach about this.

WSRP in Peoplesoft

Someone wrote me regarding WSRP advice. As often I'm reluctant to answer questions without answering them out loud and in public where others can see what is being said and either use it or disagree.

I've been developing JSR-168 Portlets for uPortal for a while and our management decided to change our portal framework from uPortal to PeopleSoft Portal. I'm hoping to reuse some of the work we've done by using WSRP. I know that uPortal has supported WSRP (except for hiccups). However, I'm having touble finding any technical information on developing a WSRP portlet (seems that there is little on the web or in printed material showing examples of WSRP code). I was wondering if you could point me towards some information regarding developing WSRP producers.

I'm reluctant to recommend WSRP as a solution to any real problem.

PeopleSoft does expose WSRP and so I suppose one could decide to
consume that WSRP in a portal. My gut reaction to the whole thing is
that it would be better architected if PeopleSoft had delivered
JSR-168 portlets that consumed domain-specific web services under the
hood. WSRP fundamentally is a protocol for remoting the production of
portlet *markup*, and that's strange.

You've articulated a different problem. You have a WSRP consuming
portal (PeopleSoft) that you'd like to get content into.

Michael Ivanov, Matthew Dovey, and others have been more involved in
uPortal WSRP.

I hear this is easier over in the .NET world, writing WSRP producers.
Don't know much about that.

In the Java world, what you do is you write a JSR-168 portlet and then
front it with WSRP4j to expose the portlet. uPortal 3 also has WSRP
producer infrastructure, such that it can produce WSRP around portlets
running in it. Sakai also produces WSRP. All of this either is or is
built on WSRP4j.

In theory you could run uPortal and use it to serve JSR-168 portlets as a WSRP Producer to a PeopleSoft portal instance which would present them to end users.