| [alf-dev] Re: Requirements for ALF SSON |
|
Last week, we had discussed some potential SSO implementations that could be included within ALF. One promising contender that also happens to be in popular use currently is the Central Authentication Service (CAS) from Yale University(http://www.yale.edu/tp/auth/cas10.html). CAS provides SSO (authentication) capability, it does not deal with authorization per se, although it may be possible to extend CAS to send along role information for authenticated principals. The following whitepaper provides a clear explanation of how CAS implements SSO and what applications have to do to enable SSO: http://www.esup-portail.org/consortium/espace/SSO_1B/cas/eunis2004/cas-eunis2004-article.pdf Both CAS and JOSSO allow for the storage of user information and credentials within a central LDAP server or database. However, if we are to provide SSO capabilities for ALF using CAS or JOSSO, the architecture will be subject to the following constraints: -All authentication for tools integrating within ALF will have to be handled by the SSO server. The proprietary authentication mechanisms present within the individual tools will have to be somehow disabled when they integrate within ALF. -The nature of SSO implies that there will be only one central repository for user information and credentials, prefereably within an LDAP server. So, any additions, modifications, etc. of user information and credentials will have to be performed within this central store. The tools participating within ALF will not maintain this information anymore. -We may also have to look at maintaining the role mappings within the central LDAP server and ensure that the SSO implementation propagates this information accordingly. -Each of the tools participating within the ALF will have to be modified in some way to enable them to participate within the SSO framework. We will of course have to ensure that any modification is minimally invasive. While I think most of the above issues would apply in the implementation of almost any ticket-based SSO system, it may be useful to focus the discussion on whether any or all of the above mentioned constraints could be potential show-stoppers. It they are, we may want to examine the feasability of implementing a full fledged SSO system within ALF and examine alternative approaches for user authentication. Please share your thoughts on the matter. Thanks, Govind Seshadri Cognizant Technology Solutions govind.seshadri@xxxxxxxxxxxxx"Kelly Shaw" <kshaw@xxxxxxxxxx> wrote in message news:devkp6$g0k$1@xxxxxxxxxxxxxxxx... > In our requirements meeting last week we decided that *requiring* an > identity server such as LDAP was beyond the scope of ALF. It sets the entry > bar too high for many products and may slow ALF adoption across the > industry. > > We did say we would provide a Service Provider Interface where an identity > server could be added to ALF. While I like this approach, I think our > example implementation should probably include something like JOSSO or some > other identity manager. > > Do I hear agreement or disagreement to this approach? > > |