liferay workshop

1C O N F I D E N T I A L

Nicolas [email protected]

With the help of Joseph Shum @ Liferay

Intalio, Leader in Open Source BPM


Agenda

1 Vision2 Liferay features3 SSO in tempo4 How CAS works5 CAS applied to tempo6 What we learned7 Demo



Intalio | Portal (some ideas)



Liferay Version 5.0

Message Boards, Blogs and Wiki, fully equipped with RSS support, email notifications, dynamic tagging, rating systems and social bookmark links. Other collaboration enhancements include:

A dynamic tagging system for user-driven categorization

AJAX-based mail client that allows users to send email directly from the portal

Shared calendars, chat and pollsDirect portlet publishing to the MySpace and

Facebook networksAbility to leverage iGoogle gadgets directly within

portal deployment



SSO in Tempo

RBAC (Role-based access control)http://csrc.nist.gov/groups/SNS/rbac/- Simple plugin- LDAP pluginToken ServiceNo credentials sent aroundPlugged with CAS .. can now supports, basic CAS, OpenID,

GoogleSAML



What is CAS ?

CAS provides enterprise single sign on service:

An open and well-documented protocolAn open-source Java server component

(also a ruby one: http://code.google.com/p/rubycas-server/)

A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others

Integrates with uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle and others

Community documentation and implementation support

An extensive community of adoptersIntalio, Leader in Open Source BPM


CAS 1.0 Basics

How CAS 1.0 works



CAS Basics



CAS Proxying Quick Walkthrough


Step One: login

To start with, log in to CAS with some invented service:https://foo.bar.com/is/cas/login?service=http://localhost/bling On successful login, CAS will redirect you to the service with a ticket appended (it doesn't matter

that the service is made up as the ticket you're after is part of the url and will appear in the location bar even if your browser can't find the resource):

http://localhost/bling?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS



Step Two (a): verify the ticket and be doneSo, playing the role of the first application (not a proxying application at this stage - lets just see

if we can get our application authenticated without proxying for now), you need to take the ticket and turn it into a username:

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-

Lyg0BdLkgdrBO9W17bXS&service=http://localhost/bling which will produce a result like: <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>

<cas:authenticationSuccess><cas:user>endjs</cas:user>

</cas:authenticationSuccess></cas:serviceResponse>

This is the end of the road for normal applications that don't need to proxy other applications.




Step Two (b): verify the ticket and enable further proxying

If instead you do want to be able to proxy other applications you need to also supply a pgtUrl to your validation request so that CAS can callback with the Proxy Granting Ticket. This is where life gets complicated, especially if you forget that service tickets are one-time-only tickets and that once you've used them with serviceValidate, you have to go back to CAS and get a new one (so if you've done Step One and Step Two (a) you'll need to do Step One again before you can do Step Two (b)).

The choice of pgtUrl here is fairly arbitrary except that it needs to be an https url and it needs to be on a server on which you can access the log files.

https://foo.bar.com/is/cas/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS&service=http://localhost/bling&pgtUrl=https://foo.bar.com/pgtCallback

results in:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>

<cas:authenticationSuccess>

<cas:user>endjs</cas:user>

<cas:proxyGrantingTicket>PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td</cas:proxyGrantingTicket>

</cas:authenticationSuccess>

</cas:serviceResponse>




Step Three: dig out the PGTNow our first application knows who the user is and has a Proxy Granting Ticket IOU. To find the

real PGT we look in the apache access log for foo.bar.com and hunt out the request made by CAS to deliver the PGT:

foo.bar.com - - [10/Dec/2003:09:28:15 +0000] "GET/pgtCallback?pgtIou=PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td&pgtId=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS HTTP/1.1" 200

13079



CAS Proxying quick walkthrough

Step Four: get a proxy ticketWith the PGT in our grasp we can make a call on CAS to give us a proxy ticket for some other

service we wish to proxy:https://foo.bar.com/is/cas/proxy?targetService=http://localhost/bongo&pgt=PGT-330-

CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS

resulting in:<cas:serviceResponse>

<cas:proxySuccess><cas:proxyTicket>PT-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket>

</cas:proxySuccess></cas:serviceResponse>



CAS Quick Walkthrough

Step Five: verify the proxy ticketNow we take on our final role for the exercise - the proxied application. The proxying application

has invoked our service url and has passed in the proxy ticket it's got. We take that ticket and validate it to find out both who the user is and which applications are in the proxy chain:

https://foo.bar.com/is/cas/proxyValidate?service=http://localhost/bongo&ticket=PT-957-ZuucXqTZ1YcJw81T3dxf

resulting in: <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>

<cas:authenticationSuccess><cas:user>endjs</cas:user><cas:proxies>

<cas:proxy>https://foo.bar.com/pgtCallback</cas:proxy></cas:proxies>

</cas:authenticationSuccess></cas:serviceResponse>



CAS Applied to Tempo - I

Get a CAS Receipt from the http session from Liferay (CASified)

CASReceipt CASreceipt = (CASReceipt) (hsr.getSession().getAttribute(CASFilter.CAS_FILTER_RECEIPT));

pgtIou = CASreceipt.getPgtIou

The pgtIou provides a way to associate the Proxy Granting Ticket with a ticket validation response without including the Proxy Granting Ticket directly in the response.

proxyTicket = ProxyTicketReceptor.getProxyTicket(pgtIou, _serviceURL) String token = _tokenService.getTokenFromTicket(proxyTicket, _serviceURL)

Then call our own User currentUser = authenticate(token, grantedRoles);



CAS Applied to tempo - II

Call Tempo TokenService

public String getTokenFromTicket(String proxyTicket, String serviceURL)

ProxyTicketValidator pv = new ProxyTicketValidator(); pv.setCasValidateUrl(_validateURL); pv.setService(serviceURL); pv.setServiceTicket(proxyTicket);

pv.validate(); if (pv.isAuthenticationSuccesful()) { String user = pv.getUser(); return createToken(user);

We now have a tempo service ticket !!



Migration of UI-FW to a portlet

Being able to display UI-FW from a portalAlso the Intalio console, BAM …Integrate with SSOWe started with pluto, as the open

source portal



Lessons learned: Switch from Pluto to Liferay

JSR-168 leaves authentication outPluto has very limited SSO supportGet many threads why it doesn’t work,

versions mismatchMigrating to Liferay was a treat



Lessons learned: Jquery from the start

ExtJS dual licensing and the GPL v3Jquery in short:http://www.slideshare.net/Sudar/a-short-introduction-to-jquery/http://www.slideshare.net/simon/jquery-in-15-minutes/

Jquery in very short: You start with 10 lines of jQuery that would have been 20 lines of tedious DOM JavaScript. By

the time you are done it’s down to two or three lines and it couldn’t get any shorter unless it read your mind.”

Simple Ajax in a breeze Search for elements in the DOM is made easy The helper function [ $() ] is a pleasure to use Most importantly: it handles cross browser compatibility. Plenty of plugings and components Doesn’t hijack the common namespace

Nested sortable example



UI-FW Portlet Demo



Thank you !!

Now’s is the perfect time to ask plenty of questions …

What you think is important (speak your mind.)


liferay workshop

Education

open source bpm

proxy ticket

cas basics intalio

basic cas

cas quick walkthrough

liferay intalio

intalio portal

ticket youre