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 BeforeAfter

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 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 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 Password- protected service Password- protected service Password- protected service PW PW PW PW PW PW PW PW PW PW 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 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 Browser Web application Authenticates without sending password Authenticates via password (once) Determines validity of user’s claimed authentication

How CAS actually works Web resource CAS Web browser S C ST ST

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 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 Portal Channel “CAS-ified” service “CAS-ified” service “CAS-ified” service CAS TGT Password

Integration strategies Portal’s “CAS client” CAS Web browser S C ST ST Portal’s initial 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 PortalCAS Web browser S C ST ST Back-end service ST

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 CAS Web browser C Web resource Web resource Non-web resource K5 realm

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 Source distribution uPortal integration example (option 1) Design paper License information My address

Q&A Alternative single sign-on systems? CAS implementation questions? uPortal integration ideas? uPortal authentication subsystem questions?