1. Groups and Permissions
Dan Ellentuck
Columbia University

2. uPortal Developers Meeting 8/7/2003 Groups and Permissions
Agenda:
Additions/Enhancements in Release 2.2
Enhancements to the Current Permission Model
Models for Collaboration with Oasis and OKI

3. Additions to be Delivered in Release 2.2
Groups:
New Filesystem Group Service. See: package org.jasig.portal.groups.filesystem and website/implementors/services/filesystemGroupService_tutorial.html
Authorization:
Model a Permission Request and Permission Response:
Request captures a question about an Owner, Principal, Activity and Target.
Response captures the answer at a specific point in time. May be cached, e.g., for certain Sources or Principals.
Authorization Source:
Implements simple request-response protocol.
Lets portal use already-existing authorization service as a client.
Portal Authorization Service has a Configuration with multiple Sources and a default Combining Policy.

4. Current uPortal Permission Model
Provides access controls for portal functions:
A Principal performs an Activity on a Target within the context provided by an Owner. This is captured by a Permission.
An authorization request asks if a Principal has a particular Permission. The response is a Boolean.
Principal is a key into the Groups system.
Activity and Target are tokens that are significant to the Owner.
The Authorization service reads and writes Permissions and responds to authorization requests by applying a PermissionPolicy to the Permissions for a Principal.
Permission
Owner
Principal
Activity
Target
Type
Effective
Expires
Permission
UP_FRAMEWORK
3.local.1
SUBSCRIBE
Chan_ID.999
GRANT
01/01/2003
null
Group
local 1
Students
e.g.,

5. Extended uPortal Permission Model
Would add support for representing organizational roles:
A Group of Principals perform a Group of Activities on a Group of Targets. This is captured by a Permission, which now more closely models a Role.
Principal, Activity and Target are Group Member keys rather than just tokens.
Group(IPersons)
local 1
Students
Permission
Owner
Principal
Activity
Target
Type
Effective
Expires
Permission
UP_FRAMEWORK
local.1
local.123
local.456
GRANT
01/01/2003
null
Group(Activities)
local
123
Basic Functions
e.g.,
Instead of multi-valued principal and single-valued activity and target, make activity and target multi-valued as well.
Group(Targets)
local
456
Student Channels

6. Collaboration Opportunities (OASIS)
eXtensible Access Control Markup Language ("XACML"): "…a common language for expressing security policy."
A Subject performs an Action on a Resource. This is captured by a Target.
The logical unit of authorization is the Rule. Rules are aggregated into Policies and PolicySets.
Each Rule is applicable to a Target , which contains attributes for Subject, Action and Resource.
A Request contains Subject, Action, Resource and possibly other attributes.
A Rule evaluated within the Context of a Request yields a Boolean Result.
The Results of evaluating the applicable Rules, Policies and PolicySets for a particular Request are combined via Combining Algorithms to yield a final Result and possibly, some Obligations.
Java implementations:
Documentation:

7. Collaboration Opportunities (OASIS)
System roles:
Policy administration point (PAP) – auth engine
Policy decision point (PDP) – rules engine
Policy enforcement point (PEP) – auth client
Policy information point (PIP) – auth store
PAP
Get Policies whose Targets match the Request
Request
______________________
Can Subject “dan” perform Action “view” on Resource a/b/c.html?
PEP
Web Application
Find Policies
PDP
PDP
Response
_____________
Yes/No/N.A./Ind.
“Let me take a look at a/b/c.html…”
PIP
User “dan”

8. Collaboration Opportunities (OKI)
OKI Open Service Interface Definition ("OSID") for Authorization:
An Agent performs a Function within a Qualifier. This is captured by an Authorization.
Agent may be an individual or a Group.
Qualifier supplies the context and may be nested.
The Agent, Function and Qualifier each contain a Type, a nested category meant to model an organization.
AuthorizationManager reads and writes Authorizations and answers authorization requests for a given Agent, Function and Qualifier.
Collaboration models:
Portal authorization service has an external OKI Source.
Authorization service acts as an OKI service provider.

9. Collaboration Opportunities (OKI)
Portal authorization service has External OKI Source:
Source adapts a separate OSID implementation to the portal authorization model.
Makes authorizations from this OKI implementation available to portal clients
OKI Adaptor
Portal Authorization Client
Portal Authorization Service
External OKI Source
OKI Client
Other Adaptor
The dooflitchies are adaptors that adapt various authorization sources to the portal authorization model.
In this design, the portal has access to the foreign authorization sources, including an OKI authorization service as a client. But the foreign OKI application clients contact the OKI authorization service via its native api, not the portal. So they do NOT have access to the portal authorization service, but the portal clients have access to the OKI service.
Internal portal Source
Other External Source
Other Client

10. Collaboration Opportunities (OKI)
Possible uPortal roles:
Authorization service acts as an OKI service provider:
Implement the Authorization OSID via a wrapper around the current portal Authorization Service.
Interoperate with OKI applications that expect to use OKI services.
OKI Adaptor
Portal Authorization Client
Portal Authorization Service
OKI Authorization Clients
Here the portal implements an OKI adaptor to make the portal authorization service present the Authorization OSID to OKI clients.
OKI clients would have access to portal authorization data as well as authorization data from any other Sources. From the point of
View of an OKI client, it would all be OKI Policy data.
Other Adaptor
Internal portal Source
Other External Source
Other Client