1. uPortal Security and CAS
Susan Bramhall
ITS Technology & Planning
Yale University

2. 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

3. Aggregating content → Aggregating authentication
Before
After
Portals push the need for single sign on
Aggregating content where different credentials are needed for every application shines a bright light on an unpleasant situation
Bringing all the apps together doesn’t solve it but it makes a solution critical

4. What we will cover
How does uPortal authenticate users in the first place?
What is the N-tier authentication problem?
How does the Yale’s model, called CAS, (Central Authentication Service) solve the problem?

5. uPortal’s pluggable security-context mechanism
Authentication support in uPortal manifested through ISecurityContext:
Key functions:
Accept IPrincipal
Accept IOpaqueCredentials
Authenticate user
Return true/false (and optionally more)

6. 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.

7. ChainingSecurityContext
Allows for a chain or a tree of providers to be called
Originally envisioned as acquiring multiple credentials at sign in
For Example:
A database connection or an LDAP initial context or Kerberos TGT
Has not turned out to be the enabling component for single sign on
For example a system in which different security domains use the same password. Authentication could take place in both domains at the time the user logs in. Credentials such as TGT, database connection would be cached for channel to use but not the pass phrase.
This is not really what is needed it turns out. Some places have the problem of multiple principals and passwords. This must be solved separately – no magic here.
We don’t really want to “logon” to all the possible services a portal user may use at the beginning – really we want to acquire these resources at the time they are requested.

8. UnionSecurityContext
Simple
Provider
(password)
CAS
Union Provider
Can sit at the top of the tree of chaining providers and present isAuthenticated status and credentials of first provider in the chain to succeed
Portal property determines whether to continue

9. N-tier authentication
Channel
Portal
So far we have covered how we authenticate users into the portal but how do we convince back end applications and services that the user is authentic?

10. 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:
Accepts university security model; doesn’t automatically adapt to it itself. You still need to provide front-end, etc.
IOpaqueCredentials
NotSoOpaqueCredentials
String getCredentials();
(Not particularly secure)

11. Caching Security Provider
A way to replay passwords by giving channels access to them
Not the best idea
May expose password to insecure use by channels
Participating applications have less security than before
If the portal is compromised users’ primary credentials are compromised
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.

12. Password caching Password- protected service Portal Channel PW PW PW
Just one of these needs to be compromised, to attack user “forever”!
Channel PW
Password-
protected
service PW PW

13. Given the drawbacks of caching and re-using passwords, what’s a better approach?
How can a web based Single Sign on System really work?

14. 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
Thank you to Shawn Bayern
Other models: Liberty, Pubcookie (Washington), MACE WebISO, Passport

15. CAS in a nutshell Authenticates via password (once) Determines
validity of user’s
claimed
authentication
Authenticates
without sending password
Browser
Web application

16. Primary benefits of CAS
Works with existing authentication infrastructures, such as Kerberos
Can be used by nearly any Web-application development environment (JSP, Servlets, ASP, Perl, mod_perl, PHP, Python, PL/SQL, and so forth) — or as a server-wide Apache module
Allows "proxy" authentication for Web portals
Lets users authenticate securely to untrusted sites (e.g., student-run sites and third-party vendors) without supplying a password directly
Is portable (written in Java: Servlets, JSP, and JSTL)
Is freely available from Yale (with source code)

17. How CAS actually works S T
Web
resource
CAS S S T
Web
browser C

18. Back to the N-tier problem
uPortal can authenticate users securely with CAS.
But it does not have first-hand knowledge of users’ credentials.
This is a good thing . . .
Except that uPortal can’t impersonate the user in order to acquire secure data for the user.

19. CAS’s solution: proxiable credentials
During validation of ST, an application acquires a proxy-granting ticket (PGT) from CAS
When the application needs access to a resource, it uses the PGT to get a proxy ticket (PT)
The application sends the PT to a back-end application.
The back-end application confirms the PT with CAS, and also gains information about who proxied the authentication.

20. Proxiable credentials illustrated
IMAP server
CAS PAM
module S T
IMP
CAS
PGT PT
PGT PT PT
Username
Identity of web resource

21. CAS Security Provider Uses CAS for primary authentication
Use CAS ProxyTicketReceptor servlet to receive PGT to be redeemed later
Exposes public method to channels to get a Proxy Service Ticket for a particular service
Back end system must be configured to validate and accept proxy credentials from uPortal

22. uPortal with CAS Provider
Channel
resource PT PT
Channel PT
Username
Identity of proxy (portal)
getCasServiceToken
CAS S T
CAS Security
Context PT
PGT IOU
getProxyTicket(pgtIou,service)
PGT
CAS
Ticket
Receptor
Servlet PT
PGT PT

23. Characteristics of CAS’s solution
Back-end applications maintain control over their data
For instance, IMAP server may assert, “The only web-based application I trust is
Default: no proxies allowed!
User logout or timeout destroys subordinate credentials
User must be “present” for proxied authentication to occur.

24. uPortal at Yale
A very brief demo

25. Finally Some words from others about experience with CAS in uPortal
Questions?
URL for CAS distribution and uPortal provider: