UPortal Authentication Options: Design and Application Shawn Bayern Research programmer, Yale University Author, Web Development with JavaServer Pages.

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 usersTo provide customized contentTo restrict portal-accessible resources

Portals also need access to third-party resources “as the user”“n-tier” authenticationSingle 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 security-context 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 IPrincipalAccept IOpaqueCredentialsAuthenticate userReturn 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

LimitationsProvides 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

passwords:

NotSoOpaqueCredentials

String getCredentials();(Not particularly secure)

IOpaqueCredentials

Password caching: Drawbacks If storing passwords can accomplish single sign-

on, why not do so? 1. uPortal instance/server must be trusted.

To accept password To store it securely

2. All network links must be secured.

3. Each individual channel must be trusted.

4. All web applications must be trusted.

5. Password confers access “forever.” Overall, user loses control of authentication

granularity.

Password caching

Portal

Channel

Channel

Channel

Password-protectedservice

Password-protectedservice

Password-protectedservice

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

PWPW

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 sign-on 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

BrowserWeb application

Authenticateswithout sending password

Authenticates

via password (once)

Determinesvalidity of user’sclaimedauthentication

How CAS actually works

Webresource

CAS

Webbrowser

S

C

S T

S T

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

Institution determines security requirements of services. May handle more than just authentication

Session management ACLs Identification Principal translation

May be platform- or server-specific 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 loginPortal 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

Portal

Channel

Channel

Channel

“CAS-ified”service

“CAS-ified”service

“CAS-ified”service

CAS TGT

Password

Integration strategies

Portal’s“CAS client”

CAS

Webbrowser

S

C

S T

S T

Portal’sinitial page

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

Service

Portal Channel

Modified“CAS-ified”service

CAS sees a single “service.”

However, this “service” consists of the portal (more specifically, a channel), and an outside CAS-ified service.

Integration strategies

Portal CAS

Webbrowser

S

C

S T

S TBack-endserviceS T

Integration strategies

Option 3: use Kerberos 5 (or similar “traditional” single sign-on system) for all network servicesCAS becomes web-based “Kerberos

user agent”• User authenticates to agent.• Agent manages tickets, proxying for the

user.

Drawback: requires substantial planning, effort, scope

Integration strategiesWeb

resource

CAS

Webbrowser

C

Webresource

Webresource

Non-webresource

K5 realm

CAS future

Support application-driven “reauthentication” requirementInstead 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?