Actually, I am beginning to like the minimal return of just the user name from the SSO login. It makes for a loosely coupled solution as long as the user names are guaranteed to be unique. That is why, may be, email addresses make for such an excellent choice of logins. So, if the user names are unique, then applications just need that to figure out whatever roles, privileges are relevant to it in its own way. The only thing needed would just be the (unique) user name.
As for JOSSO...spent some time during the last week looking at...what a waste of time!! I doubt these guys even understand what SSO is, especially in doing multiple domains and client/server trust relationships. They claim to support multiple domains...only if you define SSO as a bunch of applications just sharing the same login page(!)...instead of exactly one user session. As for doing SSO in one instance of tomcat, who cares...it is an internal feature of the server already. Clearly: JOSSO is relatively immature (relative to Yale CAS), JOSSO requires way too much client-host configuration (i.e. it is not as simple as doing just a couple of security constraints in web.xml as in Yale CAS). This is impractical to deploy client applications in a legacy production box...I would like client involvement to be limited to the context instead of some global server configuration that could mess up other older applications deployed there. May be there is a way, but I sure could not figure it out from the documentation. I simply like Yale CAS better: the loosely-coupled architecture, the much more active community, the vast number of implementations already working and, the standards based (e.g. SAML) direction in the development pipeline. If I had to "adapt" my development to an SSO (however little) it would indeed be something standards based like CAS. Uday Kari ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Battaglia Sent: Thursday, April 26, 2007 3:05 AM To: Yale CAS mailing list Subject: Re: Return More than User Name CAS 3.1 will support sending back attributes via SAML (though its possible to send it back other ways). We've built in a "Services Management" tool to allow you to control which attributes get sent back to which service. Of course, clients would have to be updated to take advantage of these new features. We're currently targeting a CAS 3.1 release for June. We will be looking for volunteers to help us update clients :-) -Scott On 4/24/07, Uday Kari <[EMAIL PROTECTED]> wrote: Excellent, Thanks. I will look into JOSSO right away...although my question was pertaining to Yale CAS. Returning XML is indeed a good idea if you wish to build a custom client to use it. However, Yale CAS provides a client which should be able to consume anything that the server throws at it (XML or whatever). If this is possible, then I think it is just a matter of some clever filter-chaining within web.xml to get from Yale CAS login to tomcat role-based login. I was just wondering if anyone had already done that and if I am able to do it, I will certainly post here. Regards, Uday Kari -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ding Kai-Jian Sent: Tuesday, April 24, 2007 10:27 AM To: [email protected] Subject: Re: Return More than User Name Uday Kari <[EMAIL PROTECTED]> writes: > > Indeed, I am VERY interesting in this capability as well (that is > returning more than just username). > > Specifically, the servlet specification seems to suggest that HTTP > request needs to > > A) return the login username as a result of request.getRemoteUser() > B) return "true" for request.isUserInRole("rolename") > C) return non-null UserPrincipal object for request.getUserPrincipal() > > Is there a way to do this "roles-aware" type of login using Yale CAS > server/client out-of-the-box for tomcat? Yes, there is out-of-box support for this within tomcat. JAAS is based on role. And I know josso(another opensource sso product) dose just what you said based on JAAS and tomcat. Do you mean CAS 3.1 M3 or later will support doing like that? But I still think returning extra info using xml (casServiceValidationSuccess.jsp??) is a better idea. _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
