Scott,
Sorry for disturbing like this, so its plausible to create an
client API thats common for both CAS and openSSO, could you give me
some suggestion on how I should proceed with,
pls
thanks
Raghu
On 2/22/09, Scott Battaglia <[email protected]> wrote:
> 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
--
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
