uportal authentication options design and application l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
uPortal Authentication Options: Design and Application PowerPoint Presentation
Download Presentation
uPortal Authentication Options: Design and Application

Loading in 2 Seconds...

play fullscreen
1 / 34

uPortal Authentication Options: Design and Application - PowerPoint PPT Presentation


  • 437 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'uPortal Authentication Options: Design and Application' - paul


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
uportal authentication options design and application

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
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
uportal and authentication
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
Question 1

How does uPortal authenticate users in the first place?

uportal s pluggable security context mechanism
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
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
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
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:

IOpaqueCredentials

NotSoOpaqueCredentials

String getCredentials();

(Not particularly secure)

password caching drawbacks
Password caching: Drawbacks
  • If storing passwords can accomplish single sign-on, why not do so?
    • uPortal instance/server must be trusted.
      • 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
Password caching

Password-

protected

service

Portal

Channel

PW

PW

PW

PW

Password-

protected

service

Channel

PW

PW

PW

PW

Channel

PW

Password-

protected

service

PW

PW

question 2
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
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
CAS in a nutshell

Authenticates

via password (once)

Determines

validity of user’s

claimed

authentication

Authenticates

without sending password

Browser

Web application

how cas actually works
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)

Side benefits of CAS
cas characteristics
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
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
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
Question 3

What is uPortal’s role in a campus-wide single sign-on framework?

cas and portals
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
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 strategies24
Integration strategies

“CAS-ified”

service

Portal

Password

Channel

“CAS-ified”

service

Channel

CAS TGT

Channel

“CAS-ified”

service

integration strategies25
Integration strategies

S

T

Portal’s

“CAS client”

CAS

S

S

T

Web

browser

C

Portal’s

initial page

integration strategies26
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 strategies27
Integration strategies

CAS

Service

Portal

Channel

CAS sees a single “service.”

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

Modified

“CAS-ified”

service

integration strategies28
Integration strategies

Back-end

service

S

T

S

T

Portal

CAS

S

S

T

Web

browser

C

integration strategies29
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 strategies30
Integration strategies

Web

resource

CAS

Non-web

resource

Web

resource

K5 realm

C

Web

browser

Web

resource

cas future
CAS future
  • Support application-driven “reauthentication” requirement
    • Instead of more complex system of “security rings” or “application groups”
summary
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.
slide33
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
    • shawn.bayern@yale.edu
slide34
Q&A
  • Alternative single sign-on systems?
  • CAS implementation questions?
  • uPortal integration ideas?
  • uPortal authentication subsystem questions?