Groups and Permissions Dan Ellentuck Columbia University

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

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.

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.,

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

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: http://sunxacml.sourceforge.net http://www.jiffysoftware.com Documentation: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml http://developer.java.sun.com/developer/technicalArticles/Security/xacml/xacml.html

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”

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.

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

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