Raghu, That's not necessarily true. Many languages, including Java, provide a standard way for applications to delegate security. I would take a look at the Servlet API and the JAAS API.
Application's that depend on the Servlet API's HttpServletRequest.getRemoteUser or HttpServletRequest.getPrincipal are not dependent on any actual client API. Those applications would merely need to be reconfigured to use the correct client, but not rewritten. For an example of this, take a look at the Jasig CAS Client for Java which exposes its Principal via the standard Servlet API mechanism. http://www.ja-sig.org/wiki/display/CASC/CAS+Client+for+Java+3.1 A security framework such as Spring Security also abstracts the different authentication mechanisms from the application and may be a good client API to look at: http://static.springsource.org/spring-security/site/index.html -Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Sun, Feb 22, 2009 at 1:02 AM, Raghu Ravi <[email protected]> wrote: > David, > Tempting it may be, but with two months at hand its a risk on > my college degree. > > I think I have explained you wrong, what I should do is this > > a) To implement openSSO the client application will have to > implement the clientAPI provided by openSSO and for CAS he has to > implement the CAS API ok. > b) Now what happens if he decides to change the server from > openSSO to CAS or vice versa. He has to reimplement the API right. > > Now I should write an API thats common for both. Multiple > protocols etc are the problem of server and identity provider, I am > concerned on the region between client application developer and the > SSO server. There protocols don't play any part right, or am I wrong > > Please correct me if I am wrong, I need your help, because in > past few days I am geeting more help from you guys than my guide. > > > On 2/21/09, David Whitehurst <[email protected]> wrote: > > Raghu: > > > > I agree with Scott. This sounds like a difficult but fun project. > Multiple > > protocols in addition to the support for multiple authentication > mechanisms > > makes a tempting code base (valuable). You can truly learn from this. > > > > Start your design by modularizing the protocols and the authentication > > methods. I would first work to fully understand the protocols and then > > diagram their use on paper. > > > > HTH > > > > David > > > > On Sat, Feb 21, 2009 at 10:20 AM, Scott Battaglia < > [email protected] > >> wrote: > > > >> Raghu, > >> > >> You best bet is that you create a server that is able to understand > >> multiple protocols. This is what we're attempting to do with CAS4 (it > >> will > >> support SAML2, CAS1, CAS2, and possibly others). Another possible > project > >> you may wish to look at is: > >> > >> https://rnd.feide.no/simplesamlphp > >> > >> It mediates between a group of protocols (much like CAS4 will do). > >> > >> Your only other choice is a framework like Spring Security, on the > client > >> side, which understands multiple authentication mechanisms. > >> > >> -Scott > >> > >> -Scott Battaglia > >> PGP Public Key Id: 0x383733AA > >> LinkedIn: http://www.linkedin.com/in/scottbattaglia > >> > >> > >> On Sat, Feb 21, 2009 at 1:05 AM, Raghu Ravi <[email protected]> > wrote: > >> > >>> David, > >>> Thank you for replying, this is my project in co,llege and i > >>> have > >>> to do it to earn my credit. The project is to build a generic API for > >>> SSO, I > >>> have chosen OpenSSO and CAS to work with, do you have any better > >>> suggestion, > >>> any other SSO that I could use. I am not getting any help, since this > is > >>> one > >>> of a kind project. > >>> The motivation is, an enterprise has to change all the client > web > >>> application when they migrate from one SSO serevr to another, eg from > CAS > >>> to > >>> OpenSSO, by using the generic API they would just have to change the > >>> server > >>> and thats it, it should work. > >>> I had no idea about single sign on until I started the > project, > >>> so I if you know a better server to work with please suggest it, > >>> > >>> thank you > >>> Raghu > >>> > >>> On Fri, Feb 20, 2009 at 6:19 PM, David Whitehurst < > [email protected] > >>> > wrote: > >>> > >>>> Raghu: > >>>> > >>>> I haven't come across anything that does this. I do think, however > that > >>>> you would need to consider what both products do collectively. Ask > >>>> yourself > >>>> "what would OpenSSO add to CAS?" How would you use such an API? Who > >>>> would > >>>> use such an API? > >>>> > >>>> I've looked at the SSO spec at Oasis and OpenSSO seems to have > captured > >>>> that need for compliance. CAS is based on a security protocol and > seems > >>>> to > >>>> be more process related where OpenSSO deals with programming needs to > >>>> support SSO communications. You also have to ask yourself is there a > >>>> true > >>>> need for a combined API? > >>>> > >>>> I don't know if I helped but I understand your motivation I think. > When > >>>> you get into the detail of CAS and SSO you may find that everything is > >>>> already there to accomplish your tasks. I don't know if you are going > >>>> to > >>>> simplify things with another API. > >>>> > >>>> David > >>>> > >>>> On Fri, Feb 20, 2009 at 3:37 AM, Raghu Ravi > >>>> <[email protected]>wrote: > >>>> > >>>>> Hi, > >>>>> I am doing a project on writing a generic API for OpenSSO and > >>>>> CAS, has anyone come across such an API or atleast an idae to proceed > >>>>> with > >>>>> with would be of great help. > >>>>> > >>>>> Thanking You > >>>>> Raghu R > >>>>> > >>>>> -- > >>>>> You are currently subscribed to [email protected] as: > >>>>> [email protected] > >>>>> > >>>>> > >>>>> > >>>>> To unsubscribe, change settings or access archives, see > >>>>> http://www.ja-sig.org/wiki/display/JSG/cas-user > >>>>> > >>>>> > >>>> -- > >>>> You are currently subscribed to [email protected] as: > >>>> [email protected] > >>>> To unsubscribe, change settings or access archives, see > >>>> http://www.ja-sig.org/wiki/display/JSG/cas-user > >>>> > >>>> > >>> -- > >>> You are currently subscribed to [email protected] as: > >>> [email protected] > >>> > >>> To unsubscribe, change settings or access archives, see > >>> http://www.ja-sig.org/wiki/display/JSG/cas-user > >>> > >>> > >> -- > >> You are currently subscribed to [email protected] as: > >> [email protected] > >> To unsubscribe, change settings or access archives, see > >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> > >> > > > > -- > > You are currently subscribed to [email protected] as: > > [email protected] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
