The Subject Portals Project SPP and its Functionality

1
The Subject Portals Project (SPP)and its
Functionality
Francisco Pinto Humbul Humanities Hub, Oxford
University, UK francisco.pinto_at_computing-services.
oxford.ac.uk Michael Fraser Humbul Humanities
Hub, Oxford University, UK mike.fraser_at_computing-s
ervices.oxford.ac.uk
2
Overview

• Contextualise SPP
• Funding Body, JISC IE
• Rationale, Deliveries Guiding Principles
• Partners, Project Structure Features
• Portals
• General, JISC SPP Perspectives
• Portal Frameworks Related Standards
• Portlets
• Functionality
• Access Management Functionality
• Athens
• LDAP/SSL
• Conclusion
• Where We Are Now
• Exit Strategy
• Demo

3
Funding Body

• Joint Information Systems Committee (JISC)
• Promote and Disseminate Best Practice
• Information Communication and Technologies (ICT)
• Higher and Further Education (HE/FE)
• Serving 600 UK Institutions
• Information Environment Context

4
Rationale

• Current UK JISC Information Environment
• Multiple Disparate Information Resources and
  Services
• Learning, Teaching Researching
• Different User Interfaces
• Search, Browse, Alert,

Difficult to Keep Always Up-To-Date

• JISC 5 Year Strategy for the Information
  Environment
• Enhance
• Visibility of the Resources
• Discovery Of and Access to Content
• Provide
• Seamless Discovery Across Multiple Content
  Providers
• Better Delivery of Electronic Collections

SPP - Learning and Teaching Call (5/99)
5
JISC Information Environment
6
Description

• SPP
• Two Year (August 2001/03)
• Develop Subject Portals
• Distributed and Collaborative Project at the RDN
  Hubs
• SPP Exit Strategy
• One Year (September 2003)
• Upgrade the Project to a Service
• Allow Hubs to Present Enhanced Subject-based
  Portal View of Relevant Content
• JISC IE Collections
• Hubs Information Resource Catalogues (IRC)
• Deliveries
• Upgrade Hub Services to Portals

7
Guiding Principles

• Distributed and Collaborative Development Team
• Support
• Portal Development in Each Hub
• Produce
• Portal Framework Independent Functionality
• Commitment Wherever Possible
• Open Source
• Open Standards
• Accessibility
• Usability

8
Partners
9
Hubs, the Subject Centres
PSIgate
Humbul
10
Hubs, the Subject Centres

• Distributed Collaborative Development Team
• Features
• Identifying Functionality
• Initial Requirements
• Questionnaire Survey
• Consultancy Groups
• Modelling the Functionality (UML)
• Common Development Environment
• Version Management (CVS)
• Synched via Email and available via HTTP
• Bug Tracking Software (RT)
• Standard Build Environment (Ant)
• Project and Developers Fora
• Web Sites
• Mailing Lists

11
Hubs, the Subject Centres

• Distributed Collaborative Development Team
• Features
• Meetings
• Virtual Weekly (IRC)
• Face-to-Face Frequently (TRAIN)
• Pub Sometimes (BEER)
• Strengths
• Sharing Knowledge
• Stopping Duplication of Effort
• Weaknesses
• Synchronisation
• Overlapping
• Tensions

12
What is a Portal in General?

• Infrastructure for Services
• Similar to a Windows-based Operating System
• Basic Services
• Windows Management
• Security
• Registry
• Services
• Similar to a Window
• GUI Applications
• Provide Access to the Content

13
What is a Portal for JISC?

• JISC Definition
• Technically, a portal is a network service that
  brings together content from diverse distributed
  resources using technologies such as cross
  searching, harvesting, and alerting, and collates
  this into an aggregated form for presentation to
  the user, usually via a website.
• Typical Features
• Single Point of Access (One Stop Shop)
• Resources Services brought together from 1
  source
• Security
• Aggregation Integration
• Personalisation Customisation (one size does
  not fit all)
• Sense of Community
• .

• Portal Types
• Subject Portals
• Institutional Portals

• Data Type Portals
• User Community Portals

14
What is a Portal for SPP?

• Portal Framework
• Supporting Software to Provide Access to the
  Content, but Independent of the Content
• Independent of the Users and Content Software
• Users Access From Anywhere
• Via Preferred Web Browser
• Seamless Access to Resources
• Built-in Functionality
• Security
• Access Management (Authentication
  Authorisation)
• Personalisation
• User/Group Profiles
• Presentation
• Variant of Model View Control (MVC) Paradigm
  (e.g. JSP, XSP, Velocity , XML/XSLT)

15
What is a Portal for SPP?

• Portlets
• Web Components such as Servlets
• Abstractions or Metaphors
• Channels, Modules, Etc.
• Plugable Functionality
• Common Integration Layer
• Between the Content and the Presentation
• Standards to Access the Content
• Z39.50, SOAP, XML/RSS, SMTP/POP3/IMAP
• Standard-based
• JSR 168, WSRP,
• Ensure Interoperability Across Different Portal
  Frameworks
• Third Party Development Potentially Reduces Time
  and Cost Becoming Crucial for the Institutions
  Core Business Infrastructure

16
Portal Framework

• Currently
• Jetspeed
• Portal Framework
• Portlets Abstraction
• Java Based
• Open Source (Apache)
• Open Standards (JSR 168, ?WSRP?)
• Exit Strategy September 2003
• uPortal
• Portal Framework
• Channel Abstraction
• Java Based
• Open Source (JA-SIG)
• Open Standards (WSRP, ?JSR 168?)

17
Best Portal Framework?

• Criteria?
• Integration with Existing Functionality
• Easy to Develop New Functionality
• Programming Language Independence
• Standards to Access Content
• Standards for Interoperability and Portability

All are Incomplete or have Deficiencies
Standards is the Solution
18
Portal Standards

• Java Specification Request (JSR) 168
• Java Community Process (JCP)
• Open Organisation of Java Developer Institutions
  with the remit to develop and revise
  specifications, reference implementations for the
  Java Platform
• Portlet Abstraction
• Java Portlet API
• Interoperability and Portability
• Status
• Community Review April 2003
• Public Review June 2003
• Release Version 1.0 August 2003

19
Portal Standards

• Web Services for Remote Portals (WSRP)
• Organization for the Advancement of Structured
  Information Standards (OASIS)
• World-Wide Consortium that Drives the
  Development, Convergence and Adoption of
  e-Business Standards
• Portlet Abstraction
• XML and Web Services to Specify, Exchange and
  Plug Portlets in any WSRP-Compliant Portal
  Framework
• Interoperability and Portability
• Status
• Approved for Public Review 31st May
• IBM and Vignette have Draft Implementations

20
Portal Standards

• JSR 168 vs. WSRP
• Work at Different Levels
• JSR 168 Specifies the Interfaces for Local
  Portlets
• WSRP Specifies the Interfaces for Exchanging
  Portlets for Remote Portal Frameworks
• Have to be Aligned
• Same Notion of the Objects
• Instantiate Locally the Portlets
• Details of the Portlet API have to be Exposed to
  WSRP in order to Exchange them

21
Functionality Identified
22
Functionality Structure
23
Functionality Integration
AccMan Package
UProfile Package
Alerting Package
XSearch Package
AccMan Facade
UProfile Facade
Alerting Facade
XSearch Facade
Auth Plugins
Alerting Daemon
XSearch Portlet
XSearch Portlet
24
SPP in the JISC IE
25
Functionality Allocation

• Portal Framework
• Bridges (ILRT)
• Plug-ins
• Access Management (HUMBUL)
• User Profiling (BIOME)
• Portlets
• Abstract Portlet (ILRT)
• Functionality
• Cross Searching (SOSIG)
• Alerting (EEVL)
• News-Feeds (PSIgate)
• Additional Services (???, Exit Strategy)

26
Access Management

• Portal Access Scenarios
• Single Web Access Point
• Common Functionality to Subject-Specific
  Information
• Resources Collected from Different Datasets
• Manage Local and Remote Users
• Access Local and Remote Resources

27
Access Management

• AMS Scopes
• Not All SPP Users Are Athens Users
• Users Want Resources Independently
• Where They Are Placed
• How They Are Protected
• From Local to National (even International) AMSs

28
Access Management

• AMS Mechanisms
• What is Secure Today May Not Be Tomorrow
• Advances in Technology Response to Risks
• Security Technology Evolves
• Moving from Username/Passwords to Single Sign-On
  (SSO) and Digital Certificates

29
Access Management System (AMS)

• Manage the Agreements Previously Established
• Institutions Resource Providers
• Ensure Authentication of Users
• Grant Authorisation to Protected Resources

30
Athens AMS

• Classical API
• Username/Password
• Athens Single-Sign On (AthensSSO)
• Login Once at the Athens Authentication Point
  (AAP )
• Authentication Protected Domain
• Use a Ticket for Every Other Athens Protected
  Resources/Services (DSP)
• Valid for a Browser Session or for 8h
• User Just Exchanges Transfer Tokens
• Valid for 60s
• Athens Single-Sign On (AthensSSO)
• Extend SSO to Access non-HTTP-SSO DSPs

31
Athens AMS

• Devolved Authentication (AthensDA)
• Institution use their own Trusted
  Authentication System
• Can be Implemented
• LDAP-based Authentication
• Digital Certificates within a PKI
• Institution's VLE
• Provide Just Authorisation
• Similar to Shibboleth (Internet2)
• Relies on AthensSSO

32
AM Athens AMS

• AthensSSO Already Integrated
• Consists of Two Parts
• AM Interceptor
• Redirects the user to the AAP
• Provides Transfer Tokens for Authentication
• AM Implementation
• Login Modules
• Integrated in the Portal Framework
• Portal Service as a Web Service via SOAP

33
AM Interceptor

• Redirects the User to the AAP
• Verifies if the User is in an Athens SSO Session
• If Not
• Asks for Credentials
• Verifies if this is the Users Preferred AMS
• If Yes
• Creates a Portal Session
• Loads the User Information from a Shared Service
  (LDAP/SSL)
• Schemas eduPerson (eduCause/Internet2) and SPP
  Private

34
AM Implementation

• AM Plug-in Integrated in the Portal Framework
• JAAS Login Modules
• Plugable Authentication Modules (PAM)
• Loaded in Run-Time According to the AMS
• Athens National AMS (NAS)
• LDAP/SSL Local AMS (LAS)

35
AM Functionality NAS
36
AM Functionality LAS
37
Conclusion Where We Are

• Access Management
• Package
• AthensSSO for National Authentication
• LDAP/SSL for Local Authentication
• Approach Proved to be Reasonable
• Flexible to Work with Multiple AMSs
• New Login Modules Developed in Few Days
• SPP is Working with X.509 Certificates
• Prepare SPP for the Future JISC AMS

38
Conclusion Where We Are

• SPP
• End of Round 2 Phase
• See Demo
• Following
• Local User Testing (15 May)
• Round 3 Phase (June/August)
• Prototype Subject Portals
• Documentation
• Dissemination
• Exit Strategy

39
Conclusion Migration to uPortal?

• Portal Framework
• Write New Bridges for Plug-ins ?
• Integrate AM Interceptor ?
• Reuse Existing Plug-ins ?
• Portlets
• Write a Bridge for the Abstract Portal ?
• Reuse Existing Functionality ?

OR
Move to Standards ?
I mean, emergent Standards ?
40
Portal Demo
41
(No Transcript)
42
Further Information

• Subject Portals Project
• http//www.portal.ac.uk/spp/
• SPP Additional Services Research
• http//www.eevl.ac.uk/public/ASP/info/
• Resource Discovery Network
• http//www.rdn.ac.uk/
• JISC
• http//www.jisc.ac.uk/
• JISC UK Information Environment
• http//www.jisc.ac.uk/dner/development/IEstrategy.
  html
• The Future of Authentication for JISC Services
• http//www.jisc.ac.uk/pub02/ar1/future_auth.html