Directorate General of Administration

Directorate of Information Technology

______

Meta-directory

Presentation of the CAS solution used for theCoE's WebSSO

This document is the property of the Council of Europe.

It may not be reproduced or communicated without the prior agreement of the author

Drafted by / Version / Drafting date / Current status
DIT / 3.0 / 27/08/2009 / validated

Directorate General of Administration

Directorate of Information Technology

______

Contents

1Preamble

2General information on how CAS works

2.1General points

2.1.1CAS server

2.1.2Web browsers

2.1.3CAS clients

2.2How CAS functions

2.2.1User authentication

2.2.2Access to a protected resource after authentication

2.2.3Access to a protected resource without previous authentication

2.3CAS architecture in place at the Council of Europe

2.3.1Technical architecture implemented

2.3.2Specific features of Intranet / Internet use

2.3.3Authentication pages

3Detailed workings of CAS

3.1Setting up authentication

3.1.1Log-in

3.1.2Validation of the "Service Ticket"

3.1.3Identity management

3.1.4Pattern of flows for a first authentication

3.2Setting up session extensions

3.2.1Session extension

3.2.2Pattern of flows for a session extension

3.3Managing log-outs

3.4Specific features

3.4.1Impersonification: managing "administrator" accounts

3.4.2Managing "mixed" applications

3.4.3Welcome page

1Preamble

To implement aWeb Single Sign-On (WebSSO) solutionfor access to itsweb applications, the Council of Europe has chosen CAS (Central Authentication Service).

CAS is aWeb SSO Opensource solution originally developed byYaleUniversityand then taken up by the JA-SIG community.

Note: the official JA-SIGCAS site is

The applications are integrated in CAS either at the level of the application throughlibraries available for different languages (.NET, PHP, ASP, C, Java etc) orof a knownCASclient already integrated in the application, or directly at the level of a Web server (Apache module for CAS forexample).

Note: the official site listing available clients is:

2Generalinformationon how CAS works

2.1Generalpoints

2.1.1CASserver

Authentication iscentralisedon aCAS server. Thisserveris the only player in the CAS mechanism whichrelays user passwordsto the centralisedLDAP directory. It has a dualrole:

  • Authenticating users;
  • Certifying the identityof the person authenticated toCAS clients via aservice ticket.

2.1.2Web browsers

Webbrowsers must comply with the followingconstraints for optimumCAS user-friendliness:

  • allow HTTPSprotocol
  • be capable of storing cookies (in particular, private cookies must be resent only to theserverwhich sent them out in order to guarantee the securityof theCASmechanism).

These requirements are met by all the typically usedbrowsers, ie Microsoft Internet Explorer (since version 5.0), Netscape Navigator (since version 4.7) and Mozilla Firefox (since the first version).

2.1.3CASclients

AWeb application equipped with aclient library or an integratedCASclientistermed a "CAS client". It delivers resources only after ensuring that the browseraccessing it has been authenticated with the CAS server. The client also runs checks on the validity of the CASsession at regular intervals.

2.2How CAS functions

2.2.1User authentication

A log-in form (figure 6) is displayed toa non-authenticated useraccessing the CAS server, or a user whose authentication hasexpired. They are asked to enter theirlog-in data (log-in/e-mailand password):

Figure 1 - Initial access by a browser to a CAS server (without TGC)

If the authenticationdata are correct, the serversends a cookie called a TGC (Ticket Granting Cookie)back to the browser:

Figure 2 - Authentication of abrowser with the CAS server

The Ticket Granting Cookie (TGC) is the user's passport for theCAS server. The lifetime of the TGC is limited to that of the browser session (once the browser is closed, the session is lost). It enables browsers to obtain tickets for CAS clients from the CASserver without the need to constantly log in again.

It is acookie that is private(sent only to the CAS server and never to any others) and protected (allbrowserqueriesto the CAS server are made under HTTPS).

Like all the tickets used in theCAS mechanism, it is opaque (contains no information on the authenticated user): it is an identifier for the session between the browser and the CAS server.

2.2.2Accessto aprotected resource after authentication

The sequence for accessing a resource protected by CASis shown below:

Figure 3 - The CAS serverredirects abrowser to aCAS client after authentication

The phases are as follows:

  • [1]: the browser attempts to access a protected resource on a CASclient;
  • [2]: the client redirectsthe browser to the CASserverin order to authenticate the user;
  • [3]: the browser, having been authenticated with theCAS server, submits the TGC (cookie)to it;
  • [4]: When the TGC is submitted, the CAS server deliversa Service Ticket (ST) to the browser; this is an opaque ticket, carrying nopersonal information; it can be used only by the"service" (URL) which has requested it;
  • [5]: At the same time, the CAS server redirects the browserto the requesting service by supplying the Service Ticket as aCGI parameter;
  • [6] and [7]: the Service Ticket is then validated with the CAS server by theCAS client, directly in HTTP;
  • [8]: the resource isdeliveredto the browser.

Note: all the redirecting processes arecompletelyinvisible to the user,who does notsee them and has the impression that they aredirectly accessingthe desired resource, without authentication, as the diagram below shows:

Figure 4 - User view of theauthenticationmechanism

The Service Ticket (ST) is the user's passport for aCAS client. It is not reusable (may be submitted to the CAS server only once), it islimitedto a single CAS client and its lifespan is very limited (usually a few seconds).

2.2.3Access to a protected resourcewithout previous authentication

Ifthe useris not already authenticatedwith the CAS server before accessing a resource, their browser is redirected, as above, tothe CAS server, and anauthenticationform is displayed.

When the browser submits the form to theCAS server, if the informationsupplied is correct, the CAS server:

  • delivers a TGC (Ticket Granting Cookie) to theuser, which means that they will not have to repeat log-in later;
  • issues theuserwith a Service Ticket for theCAS client;
  • Redirects the usertothe CAS client.

Accordingly, previous authenticationis notnecessaryto access a protected resource.

2.3CAS architecture in place at theCouncil of Europe

2.3.1Technical architecture implemented

In the architecture in place at theCouncil of Europe, all the nodes making up the authentication platformare redundant to guarantee continuityof service:

  • the "user" databaseroleis played by theid.coe.int Meta-directory (Microsoft ADAM directory), which is redundant andpowered by the Microsoft Forefront Identity Manager (FIM)synchronisation enginedrawing the data from theCouncil of Europe'sdifferentbases ofActive Directory accounts;
  • two CASservers are configured in an active-passivecluster (if the active servergoes down, thepassiveserver automatically takes over but the users lose their session and have to log back in);
  • the CAS servers are positioned behind the reverse proxy, which is also redundant in active-passive mode.

2.3.2Specific features of Intranet / Internet use

System behaviourdiffers, depending on whether users connect from the Intranet or the Internet).

Connection from / Ticket Granting Cookie TGC / Validity ofauthenticationpage
Intranet / Type: persistent (written to disk).
Validity: 1 month. / 4 hours.
Internet / Type: non-persistent (not written to disk).
Validity: 4 hoursandexpires whenweb browser is closed. / 5 minutes:to prevent revalidation of the form by going back.

Figure 5 - Architecture used at the Council of Europe

2.3.3Authentication pages

The CASauthentication pages have been customised (see below):

Figure 6 - CAS Login page for CoE

Figure 7 - CAS Log-out page for the CoE

Figure 8 - CAS error page for the CoE

3Detailed workings of CAS

3.1Setting up authentication

3.1.1Log-in

To authenticatethe user, the application must redirectthe usertothe CAS server, and the URL (service to be validated) must be submitted as aparameterto the request. It is thisURLwhich will then be used bythe CAS serverto return to the desired page:

service=

The CAS serverthen authenticatesthe userand sends back a"Service Ticket"in the form of aparameterwhich must be retrieved so that it can be validated later by the application.

ticket=ST-12345678

3.1.2Validation of the"Service Ticket"

This ticket has a lifetime of 20 seconds. The application must validate it by calling up the"ServiceValidate"pageof theCAS server:

serviceValidate?service==ST-12345678

An XML flow isrecovered in response to this request, it contains theauthenticated user's e-mail address in a <cas:user>tag:

<cas:serviceResponse xmlns:cas='

<cas:authenticationSuccess>

<cas:user></cas:user>

</cas:authenticationSuccess>

</cas:serviceResponse>

Note: the "Service ticket" may be validated only onceand has a lifetime of 20seconds. In the event of expiry or error, the XMLflowreturns an error code:

<cas:serviceResponse xmlns:cas='

<cas:authenticationFailure code='INVALID_TICKET'>

ticket ST-XXXXXXXXX; is unknown

</cas:authenticationFailure>

</cas:serviceResponse>

The other error codes which may be returned are:

INVALID_REQUEST / Certainparametersare incorrect or notpresent
INVALID_TICKET / The ticket submitted is not valid, the detailsare given in the <cas:authenticationFailure> blockof the XML response returned.
INVALID_SERVICE / The ticket submitted is validbut the service specifieddoes not correspond to the ticket submitted, so the ticket has been invalidated, andanother ticket will have to be requested for that service.
INTERNAL_ERROR / Aninternal erroroccurred on theCAS serverduring ticket validation.

3.1.3Identity management

Once the user'sidentity is known, it must be stored in asession variable specific to the application according to the mechanismswhich are standardfor thattechnology.

The permissions androlesmust then be managed by the application on the basis of thatsession variable.

3.1.4Pattern of flows for a firstauthentication

The diagrambelow shows thedifferentqueries and checks to be made during a user's firstauthenticationby an application which usesWeb SSO.

Integration of a web application in the CoE's Web SSO CAS1/19

Direction Générale de l'Administration et de la Logistique

Service des Technologies de l'Information

______

3.2Setting up session extensions

3.2.1Session extension

Every 5 minutes (it must be possible to modify this duration via aconfiguration file), a new"Service ticket"must be requested and then validated with theCAS serverin order to refresh the content of theapplication's session variable.

If the CASsession:

  • is still valid: the CASsessionis extended (shifting of theuser'ssession on the CAS server);
  • is no longer valid (expiry or log-out from another application): theapplication session must be cleared, and themechanism willautomatically redirectthe userto thelog-in page.

3.2.2Pattern of flows for asession extension

The diagram below shows the different queries and checks to be made for asession extension or when a second application needs to identify a user already running a session on theCAS server.

Intégration d’une application web dans le Web SSO CAS du CoE1/19

Direction Générale de l'Administration et de la Logistique

Service des Technologies de l'Information

______

3.3Managinglog-outs

The key point about managing log-outsis that a log-out from the application alone will not work. The CAS mechanism automaticallyreconnectsthe userto the application when they attempt to access it. To be taken into account, theapplication log-out must be coupled with theCAS log-out but in that case the CAS session will be closed for all the other applications.

Therefore, a choice has to be made between the followingpossibilities:

  • SSO log-out +application log-out. Theapplicationsession must be cleared and theCAS log-out carried out as above.
  • SSO log-out only (a link to the The user then closes their browser or is redirected to theapplication welcome page for unidentified userswhere one exists (see Welcome pagesection below). In this case, the applicationsession is kept running.

Recommendation:For each application for whichweb SSO integration is desired, the following approach must be taken if possible:

  • The current "log-out" buttonsmust be renamed as "close this application". The roleof thisbuttonwill be to log work in progress and then toredirect the user to the application'swelcome page if it has one or, if not, to theIntranet/Internetportal.

It should be noted that if the user does not use thisbuttonand directly closes the browser tab, as happens now, the work in progress will not be saved.

  • A second button"SSOlog-out " or "close mySSO session" must be added to each application. Thisbuttonenables the user to log out from their "SSO session". When the user clicks on this newbutton, a pop-up informs them that thisoperationwill close notonly this application but also all the other applications opened.

Exampleof a pop-up:

French version of text:

Attention : vous allez fermer toutes vos applications web et risquez de perdre toutes vos données non sauvegardées.

Voulez-vous vraiment vous déconnecter et fermer votre session SSO ?

English version of text:

Warning: you will close all your web applications and may lose all your unsaved data.

Do you really want to sign out and close your SSO session?

3.4Specific features

3.4.1Impersonification: managing"administrator" accounts

If the application has "administrator" accounts which are notreferenced in the central authenticationsystem, the application will have to manage them as exceptions. The users of these accounts must access this application from a log-in form which is differentfrom the one provided by WebSSO.

3.4.2Managing"mixed"applications

Some applications may be "mixed", with one unrestrictedpart and one restrictedpart which requiresauthentication.

Users must accesssuch applicationsvia apage for unidentified users for the unrestricted part andviathe WebSSO CAS for the restricted part.

3.4.3Welcome page

To deal with the previous issues (managing "administrator" accountsand managing "mixed" applications), a point of entryhas to be set up: a welcome page (application portal)for unidentified users.

This page must display a linkfor logging in: clicking on that link will trigger theWebSSO CASauthentication mechanism.

If access via administrator" accounts isnecessary, a linkto the"administration"part could alsobe included on this welcome page.

In the event of prior authentication via WebSSO CAS, this page must inform the user, in sufficiently clear terms, by displaying somepersonal details, for example: "Welcome John Doe".

Finally, where applicable, this page could be used to directusers in relation to usercategories: in-house users at the Council of Europe, external users, application administrators etc.

The diagram below shows the redirection flows to be implemented when a welcome page is used:

Intégration d’une application web dans le Web SSO CAS du CoE1/19

End of document