Us­ing a Sin­gle Sign-on in Java based Web Ap­pli­ca­tions

Au­then­ti­ca­tion to sev­eral re­lated but in­de­pen­dent soft­ware sys­tems by log­ging in with a sin­gle user ID and pass­word is called sin­gle sign-on. It is an ac­cess con­trol prop­erty, whereby the user can seam­lessly gain ac­cess to mul­ti­ple con­nected sys­tems witho

OpenSource For You - - Contents - By: Magesh Kasthuri The au­thor is a se­nior distin­guished mem­ber of the tech­ni­cal staff at Wipro. He is an en­ter­prise ar­chi­tect in BFSI, and can be reached at

Web ap­pli­ca­tion de­vel­op­ment is one of the most pop­u­lar ar­eas in IT soft­ware de­vel­op­ment. With clients be­com­ing smarter, de­sign ar­chi­tects and so­lu­tions providers are spend­ing most of their time in the re­search and de­vel­op­ment of quicker, cheaper, more flex­i­ble and com­pre­hen­sive so­lu­tions to suit any com­plex need of the user.

Of the many as­pects of Web ap­pli­ca­tion de­vel­op­ment (or Web apps in a techie’s lan­guage), the most chal­leng­ing and in­ter­est­ing sub-sec­tion is the au­tho­ri­sa­tion and sign-on fa­cil­ity for a Web app.

The most ac­cepted and com­mon way of au­tho­ri­sa­tion is the log in/pass­word, which the user has to sup­ply. This is counter-matched with the records in the store (a data­base, usu­ally) and per­mis­sion is granted based on cri­te­ria like roles and per­mis­sions.

As cus­tomer de­mands grow more com­plex, the sit­u­a­tion be­comes chal­leng­ing when the de­vel­op­ment com­mu­nity is given more than one Web app in­ter­linked for dif­fer­ent pur­poses, and is asked to pro­vide a sign-on for them.

This is when a sin­gle sign-on (SSO) makes sense. This ar­ti­cle looks at its ex­act mean­ing, why it is re­quired and how it got its cur­rent shape. We will also briefly dis­cuss the var­i­ous fa­cil­i­ties/tech­nolo­gies avail­able nowa­days for the sin­gle sign-on.

SSO: In the early phase of adop­tion

To han­dle au­then­ti­ca­tion for dif­fer­ent Web apps us­ing sin­gle sign-on in­for­ma­tion, cer­tain fea­tures were pro­posed ear­lier. Two of th­ese are listed be­low.

By­pass lo­gin: A by­pass lo­gin is a crude work­around to han­dle lo­gins for mul­ti­ple re­lated Web apps. It han­dles a lo­gin to the se­cond ap­pli­ca­tion with a flag as a cookie set dur­ing the first Web app lo­gin. If this flag is set, then the se­cond

Web app will log in au­to­mat­i­cally. There is a huge prob­lem in this method as the se­cond Web app will not be role or

pol­icy based and hence will have the same amount of ac­cess/ fa­cil­i­ties for any lo­gin.

More­over, the se­cu­rity of the se­cond Web app’s lo­gin is not guar­an­teed. To over­come this, there was a mi­nor change done in the by­pass lo­gin, whereby there is an ex­tra pa­ram­e­ter passed from the first Web app to the se­cond one, which is the key to ac­cess the se­cond Web app.

The draw­back in this process is that there is al­ways the de­pen­dency of the key pa­ram­e­ter, and the se­cond Web app has to be al­ways called from the first one (sched­uled or au­to­mated tasks can­not be run).

Web ser­vice call: This is gen­er­ally used when the se­cond and sub­se­quent Web apps ex­pose cer­tain Web ser­vices, and the first Web app in­vokes calls to th­ese Web apps through th­ese Web ser­vice calls. The prob­lem in this fea­ture is that the de­vel­oper is more de­pen­dent on the struc­ture of the in­put/ out­put of the Web ser­vice and is bound to han­dle all re­quests through them only.

What is sin­gle sign-on?

Though a by­pass lo­gin and Web ser­vice call pro­vide fa­cil­i­ties to skip sub­se­quent lo­gins to dif­fer­ent Web apps, there are some draw­backs in their over­all ar­chi­tec­ture, as seen ear­lier. If we first un­der­stand the need for us­ing mul­ti­ple Web apps, we can eas­ily grasp why a sin­gle sign-on is re­quired.

Con­sider a com­plex en­ter­prise Web app for a tex­tile firm which in­volves var­i­ous op­er­a­tions like or­der­ing, sam­ples, mail­ing, de­sign­ing, etc. If we de­velop a sin­gle

Web app to cater to all th­ese needs, then main­tain­ing it will be highly com­plex.

A ser­vice provider com­pany that de­signs soft­ware for dif­fer­ent in­dus­tries will be al­ways in­ter­ested in de­vel­op­ing in­di­vid­ual mod­ules and in­te­grat­ing the re­quired pieces when de­sired. This will help in the siz­ing of the mod­ule and its main­te­nance. The process and ben­e­fits of this ap­proach are as fol­lows:

Us­age of dif­fer­ent tech­nolo­gies in dif­fer­ent mod­ules, de­pend­ing on what the mod­ule is re­quired to do.

Easy us­age and faster work due to the del­e­ga­tion of sev­eral ac­tions in par­al­lel across dif­fer­ent mod­ules. Al­lows for the re­use of the mod­ules for dif­fer­ent Web so­lu­tions, as and when re­quired.

Now when we think of a sin­gle sign-on fa­cil­ity for the above case, it’s very ob­vi­ous that a by­pass lo­gin or a

Web ser­vice call can­not be ad­van­ta­geous in such real-time sit­u­a­tions; in fact, they may fur­ther com­pli­cate the so­lu­tion as it grows big­ger in order to in­te­grate more and more mod­ules.

In short, sin­gle sign-on is a fa­cil­ity to skip or use the lo­gin in­for­ma­tion used in the first Web app for all sub­se­quent Web apps with­out pop­ping out the lo­gin screen for each one. There are many stan­dard tech­nolo­gies and tech­niques used for SSO in the in­dus­try, and many of them are open source or free­ware. We will dis­cuss some of the most pop­u­lar and ro­bust tech­nolo­gies here.

But be­fore delv­ing fur­ther into the topic, let me share the terms that are go­ing to be used here­after, along with their mean­ing and us­age.

LDAP – Light­weight Direc­tory Ac­cess Pro­to­col: This is a pro­to­col used com­monly in Web apps for look­ing up cer­tain in­for­ma­tion from the servers; it is widely used in mail servers.

Data­s­tore: This is the store in LDAP that keeps au­then­ti­ca­tion and other ac­cess re­lated data.

Direc­tory server: This pro­vides the data­s­tore for LDAP and sup­ports many pro­to­cols in­ter­nally.

Au­then­ti­ca­tion: This is a piece of in­for­ma­tion that is ver­i­fied to cer­tify or deny ac­cess, like the user name/pass­word.

Realms: This is a kind of group or sys­tem to pro­vide fa­cil­i­ties for au­then­ti­ca­tion. It of­fers a lot of fea­tures for con­fig­u­ra­tion like pol­icy set­ting, ac­cess con­trol, priv­i­leges for realms, etc, which can be eas­ily con­fig­ured for role based ac­cess for dif­fer­ent groups and lo­gins. There are two con­fig­u­ra­tions in OpenSSO -- De­fault and New Con­fig. The De­fault con­fig­u­ra­tion is easy. The ad­van­tage is that it can be cus­tomised later and hence is meant for ba­sic or first-time users. New Con­fig, how­ever, is meant for ad­vanced users, and there may be some prob­lems with get­ting the direc­tory ser­vice port or cookie do­main if the user doesn’t know each con­fig­u­ra­tion set­ting and doesn’t pro­vide them.


One of the most pop­u­lar and com­monly used sin­gle sign-on so­lu­tions for Java Web apps is OAuth or OAuth 2.0, as the

API li­brary pro­vided has a com­pre­hen­sive fa­cil­ity for easy con­fig­u­ra­tion, and it can be used with dif­fer­ent ap­pli­ca­tion servers and a com­plex Web com­po­nent ar­chi­tec­ture. But there are many other open source SSO frame­works avail­able, too, which are listed be­low.


This is more flex­i­ble in con­fig­u­ra­tion as it has its own Web app and comes with a GUI based so­phis­ti­cated con­fig­u­ra­tion screen, which can be used to con­fig­ure set­tings for a Web con­tainer us­ing dif­fer­ent Web apps for a sin­gle sign-on.

It also needs an LDAP (we will dis­cuss this later) and a direc­tory ser­vice for han­dling SSO au­then­ti­ca­tion and a data store. It has a de­fault con­fig­u­ra­tion, which uses generic LDAPv3. We can con­fig­ure it us­ing the Sun Java Sys­tem Direc­tory Server for the data store.


JOSSO is another fa­cil­ity for SSO which is purely Java based and is also called Java Open SSO. The new ver­sion of JOSSO (1.6) sup­ports all the lat­est Web servers like JBoss 4.2. This is a widely used so­lu­tion, and the con­fig­u­ra­tion is com­par­a­tively eas­ier than OpenSSO.

There are some prob­lems that can arise in JOSSO (as dis­cussed a lot in JOSSO fo­rums), par­tic­u­larly in re­la­tion to JaasSe­cu­ri­tyMan­ager in JBoss 4.x, which was not the case with JBoss 3.x. Also, with some proxy set­tings, JOSSO can be dif­fi­cult to con­fig­ure.

JOSSO can also be con­fig­ured with LDAP, and it uses in­ter­nal JAAS from JBoss for au­then­ti­ca­tion.


OpenLDAP is an open source provider of the SSO fa­cil­ity. It is com­plex to use but has a lot of fea­tures for au­then­ti­ca­tion and con­fig­u­ra­tion. OpenLDAP can­not be used alone, as it also re­quires an SSO ap­pli­ca­tion (like OpenSSO) for han­dling lo­gins. We can use a com­bi­na­tion of OpenSSO with OpenLDAP con­fig­u­ra­tion. The main draw­back in this open source ap­pli­ca­tion is that there is no good doc­u­men­ta­tion for con­fig­ur­ing and set­ting it up.

Apache Direc­tory Stu­dio

This is so­phis­ti­cated tech­nol­ogy which can be used as a cus­tom au­then­ti­ca­tion fa­cil­ity to the level that the user wants. The draw­back, if any, is that Apache Direc­tory server is sup­ported only in Mac OS X, Linux and Win­dows.


SpringLDAP is a com­pre­hen­sive LDAP fea­ture from the Spring frame­work but it doesn’t work for SSO. It is meant for LDAP pro­vi­sion­ing for direc­tory ser­vices. Hence, it can be used with an SSO ap­pli­ca­tion for han­dling direc­tory ser­vices.

There is a sub-mod­ule in the Spring frame­work called Acegi se­cu­rity, which can be used for SSO with LDAP. It has an easy-to-use ap­proach called ‘per­sis­tent lo­gin cookie’ to by­pass lo­gin. This is also called Re­mem­berMe.

The Re­mem­berMe fa­cil­ity has two types of ap­proaches: It stores lo­gin in­for­ma­tion (base64 en­crypted) in a cookie. It stores lo­gin in­for­ma­tion (base64 en­crypted) in a data­base.

For the se­cond ap­proach, we need a ta­ble called ‘per­sis­tent lo­gins’ with user de­tails (which needs mi­gra­tion if your cur­rent Web app uses a dif­fer­ent ta­ble/data­base for user in­for­ma­tion). The first ap­proach can be sim­ple and easy-touse, but de­pends on the client fa­cil­ity to en­able cook­ies.


Liferay is a ready-to-use por­tal ser­vice provider that has a lot of tech­nolo­gies em­bed­ded in it to ad­dress the var­i­ous re­quire­ments of a Web so­lu­tion. Liferay sup­ports SSO us­ing CAS (Cen­tral Au­then­ti­ca­tion Ser­vice) from Yale. This is an open source SSO so­lu­tion. Please note that CAS re­quires cer­tifi­cate au­then­ti­ca­tion cre­ated us­ing a key tool. Also, CAS sup­ports the Re­mem­berMe fea­ture like the one ex­plained above (Spring Acegi Re­mem­berMe).

Liferay sup­ports many other SSO ap­pli­ca­tions like NTLM (not free­ware) and OpenSSO; it also sup­ports LDAP and JAAS. The tech­ni­cal spec­i­fi­ca­tions of Liferay are given at­uct/tech-specs.

The Liferay ad­min guide (liferay-ad­min­is­tra­tionguide-5.1.pdf) gives de­tails on CAS, OpenID and other

SSO so­lu­tions sup­ported by Liferay, as well as on us­ing Liferay with dif­fer­ent ap­pli­ca­tion servers. [It has de­tails on con­fig­ur­ing JAAS and con­fig­ur­ing SSO in all the lat­est Web servers for Liferay.]

This ar­ti­cle just helps in giv­ing read­ers a feel of the dif­fer­ent tech­nolo­gies that can be used and doesn’t in­tend to be a user guide. It is up to the ar­chi­tect and de­signer to eval­u­ate and an­a­lyse th­ese tech­nolo­gies based on their ac­tual re­quire­ments and band­width of us­age.

Fig­ure 1: By­pass lo­gin

Fig­ure 2: Sin­gle sign-on

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.