uPortal Authentication Options:
Design and Application
Shawn Bayern
Research programmer, Yale University
 Author, Web Development with JavaServer Pages
 JSTL implementation lead (JCP, Apache)

Portal authentication

Portals need to authenticate users
To provide customized content
 To restrict portal-accessible resources


Portals also need access to third-party
resources “as the user”
“n-tier” authentication
 Single sign-on

Aggregating content →
Aggregating authentication
Before
After
N-tier authentication
Portal
uPortal and authentication

Three key questions to answer today:

How does uPortal authenticate users? Will
its support work at your school?

What does a sample single sign-on system
look like?

How can uPortal interface with campus-wide
single sign-on?
Question 1
How does uPortal authenticate
users in the first place?
uPortal’s pluggable securitycontext mechanism

Authentication support in uPortal
manifested through three key interfaces:

ISecurityContext
• Instance of authentication system (“engine”)

IPrincipal
• Context-specific user

IOpaqueCredentials
• Context-specific credential (e.g., password)
• Kept safe
ISecurityContext
Interface representing single-use
authentication engine.
 Key function:

Accept IPrincipal
 Accept IOpaqueCredentials
 Authenticate user
 Return true/false (and optionally more)

uPortal’s authentication
infrastructure: advantages

Flexibility

Adapts to nearly any back-end
campus authentication solution – e.g.,
•
•
•
•

Kerberos (4, 5)
LDAP “authentication”
Unix password file (small-scale)
Server-based authentication (“trust”)
Supports “chaining” providers to
establish more than one context.
uPortal’s authentication
infrastructure: disadvantages

Limitations
Provides unified authentication “gate,”
but no extra portal-specific
functionality. No single sign-on.
 Just a model—does little work itself.
 But… can be wrenched to cache
IOpaqueCredentials
passwords:

NotSoOpaqueCredentials
(Not particularly secure)
String getCredentials();
Password caching:
Drawbacks

If storing passwords can accomplish single signon, why not do so?
1.
uPortal instance/server must be trusted.


2.
3.
4.
5.

To accept password
To store it securely
All network links must be secured.
Each individual channel must be trusted.
All web applications must be trusted.
Password confers access “forever.”
Overall, user loses control of authentication
granularity.
Password caching
PW
PW
PW
Passwordprotected
service
PW
Channel
PW
PW
PW
Channel
Passwordprotected
service
PW
PW
Portal
Channel
PW
Passwordprotected
service
PW
Question 2
Given the drawbacks of caching and
re-using passwords, what’s a better
approach?
How can a true “single sign-on”
system work on the web?
Web-based single sign-on

Why is this problem different from existing single signon systems?
 Limited client support

Yale’s model is called CAS (Central Authentication
Service). Model based (loosely) on Kerberos.
 “100% Pure Java”
 Pluggable back-end
 Available through JA-SIG Clearinghouse

Other models: Liberty, Pubcookie (Washington),
MACE WebISO, Passport
CAS in a nutshell
Browser
Web application
How CAS actually works
S
T
Web
resource
CAS
S
S
T
Web
browser
C
Side benefits of CAS

Users can be
asked to avoid
supplying
password except to
trusted site.



Expected URL
Known “look and
feel”
Authentic peer
certificate (if
anyone cares)
CAS characteristics

Requires no service pre-registration





Services are not privileged; may only
compromise themselves.
Supports but does not require cookies
Uses but does not require JavaScript
Usable by multiple languages, systems
(Java, C, JSP tags, ASP, Perl)
Free and open-source

Implemented using Java servlets
CAS at Yale

Used by systems in support of students and
staff.



Used occasionally by unprivileged students.
Mostly Java, Perl. Some ASP.
Apache module becoming widely used



C implementation of CAS “client” within
Apache server
Server-wide authentication
AuthType CAS → REMOTE_USER
Characteristics of alternative
systems

Typically require pre-registration


May handle more than just authentication





Session management
ACLs
Identification
Principal translation
May be platform- or server-specific



Institution determines security requirements of services.
Passport (Windows)
Pubcookie (Apache Server)
May depend on particular institutional characteristics—e.g.,


Network topology
Service hosting on institutionally managed web servers
Question 3
What is uPortal’s role in a
campus-wide single sign-on
framework?
CAS and portals

Using CAS as an example of campus-wide single sign-on
service…

How to use single sign-on within portal?


Unlike many applications, a portal is not the
source of all the information it vends.
“n-tier” authentication problem
• How to avoid several “bad things”?
• Password caching
• Excessive trust of portal
• Modifying legacy systems
• Balancing objectives
Integration strategies

Option 1: insert portal into initial CAS
login
Portal receives password, then
redirects the user to CAS and coerces
the browser to re-send the password
 User ends up with CAS ticket.
 Portal ends up with CAS ticket too

• Password caching isn’t precluded, but it’s
not necessary either.
Integration strategies
“CAS-ified”
service
Password
Channel
“CAS-ified”
service
Channel
CAS TGT
Portal
Channel
“CAS-ified”
service
Integration strategies
S
T
Portal’s
“CAS client”
CAS
S
S
T
Portal’s
initial page
Web
browser
C
Integration strategies

Option 2: CAS services can be made aware
of uPortal



Services simply use CAS, but acknowledge
a URL “owned” by uPortal.
Advantages: uPortal need not be trusted or
especially secure.
Drawbacks: services need to be modified
and made portal-aware.
• If you are already allowed to do this, you’re not
facing difficult hurdles anyway!
Integration strategies
CAS
Portal
Channel
CAS sees a single “service.”
Modified
“CAS-ified”
service
Service
However, this “service” consists of the
portal (more specifically, a channel),
and an outside CAS-ified service.
Integration strategies
S
T
Back-end
service
S
Portal
CAS
S
S
T
T
Web
browser
C
Integration strategies

Option 3: use Kerberos 5 (or similar
“traditional” single sign-on system) for
all network services

CAS becomes web-based “Kerberos
user agent”
• User authenticates to agent.
• Agent manages tickets, proxying for the
user.

Drawback: requires substantial
planning, effort, scope
Integration strategies
Web
resource
Non-web
resource
CAS
Web
resource
K5 realm
C
Web
resource
Web
browser
CAS future

Support application-driven
“reauthentication” requirement

Instead of more complex system of
“security rings” or “application groups”
Summary

uPortal has two uses for
authentication:
Customizing its own presentation.
 Accessing secure resources

Caching passwords is generally a
security risk.
 Models like CAS let you avoid caching
passwords.

URLs

CAS distribution


JA-SIG Clearinghouse
http://www.yale.edu/tp/cas/
•
•
•
•

Source distribution
uPortal integration example (option 1)
Design paper
License information
My email address

[email protected]
Q&A

Alternative single sign-on systems?

CAS implementation questions?

uPortal integration ideas?

uPortal authentication subsystem
questions?
Descargar

uPortal Authentication Options: Design and Applicability