Hi Brian, My understanding is CASShib and and shib-cas-authenticator are solving opposite problems.
CASShib bridges from Shibboleth to CAS (hacking the CAS protocol to support attributes). shib-cas-authenticator bridges from CAS to Shibboleth. CASShib provides a way for relying parties to consume SAML IdPs via the CAS abstraction. CASify your application, point it at a CASShib-enhanced-CAS-server, and you're now a SAML Service Provider, so long as CASShib is properly configured. CASShib is concerned with things like isolating the SSO sessions backed by authentication via different SAML IdPs to the CASShib server, e.g. CASShib is allowing users to use one of multiple SAML (Shibboleth) IdPs to authenticate to a CAS server, and then using CAS to authenticate to applications (relying parties that are making use of one of the several CAS Client software libraries, say). Some slides illustrating a usage of CASShib: http://www.internet2.edu/presentations/fall10/20101103-minimally_invasive_domestication-petro.pdf (starting at slide 45 or so). Contrastingly, shib-cas-authenticator solves using CAS to log in to a Shibboleth IdP, with certain improvements over simply using the Shib IdP's container authentication support and an off-the-shelf REMOTE_USER asserting CAS client library to accomplish this integration. shib-cas-authenticator is allowing users to use CAS to authenticate to a Shibboleth IdP, and then use that IdP to authenticate to SAML Service Provider applications (relying parties accepting SAML). Since the user is also logging in to CAS, in a shib-cas-authenticator environment both CAS-relying and SAML-relying applications can provide users a seamless single sign-on experience. CASShib bridges from Shibboleth to CAS (hacking the CAS protocol to support attributes). shib-cas-authenticator bridges from CAS to Shibboleth. In the context of the conversation about CAS server SAML support, doing attribute release via SAML, etc., shib-cas-authenticator provides one path for an adopter to, by combining CAS and Shibboleth, achieve thorough SAML 2 standard support while continuing to use the CAS login user experience and continuing to support the CAS protocol and feature-set. Interesting specifically in the context of the let's-evolve-the-CAS-protocol-to-support-attributes discussion, CASShib makes use of the unofficial CAS protocol extension to support attributes: [1] the CAS client must be "attribute aware." The CAS2 Protocol specification does not specify a way to release information in the protocol, but the JA-SIG Java Client and potentially others support an unofficial extension to the CAS2 protocol for attribute information. Other clients may have to be modified to support this, or the end application may be able to get at the raw XML data via the client and parse out the attribute information on their own. ... Kind regards, Andrew [1]: http://code.google.com/p/casshib/wiki/CASShibExplained#Using_a_CAS_client On Jan 5, 2012, at 11:13 PM, b savage wrote: > Dmitriy, > > How does this bridge contrast with CASShib > http://code.google.com/p/casshib/wiki/CASShibExplained#Shibboleth's_role > - possibly misreading but they sound similar in terms of using Shib for login > form and attribute release (CASShib may be doing some formatting of > attributes in the process) and CAS for authentication. > > Thanks for any clarification. > > Brian > > On Thu, Jan 5, 2012 at 4:52 AM, Dmitriy Kopylenko > <dmitriy.kopyle...@gmail.com> wrote: > FWIW, if one wish to use the full power of SAML, just look at Shibboleth > IDP/SP model. IMO, it deals with this complex domain rather well. > > On the other hand, CAS excels in the area of delegated authentication with > wonderful, powerful and lightweight user experience. > > So in the effort to "marry" the two together, recently a lightweight bridge > between CAS and Shib IDP has been developed. It uses Shib for SSO, powerful > attributes management, and all that jazz, but delegates to CAS for an > "external" authn and wonderful user experience. > > CAS and Shib - a powerful combo used together :-) > > https://github.com/Unicon/shib-cas-authenticator > > Cheers, > Dmitriy. > > Sent from my iPad > > On Jan 4, 2012, at 5:31 AM, Daniel Roig <droi...@gmail.com> wrote: > >> Hi guys! >> >> I just recently joined this list and thought that I should put in my two >> cents in this matter. >> >> I'm currently trying to deploy CAS at a customer's site and I have worked >> with several Access Management/SSO products and other related security >> technologies for many years and was keen on trying out CAS for this purpose. >> One thing that struck me as a bit odd is that if you don't use SAML, you >> don't get the attribute release functionality. I would love to have this >> functionality for regular CAS tickets as well. >> >> Since it is a basic CAS tenet that it should *only* handle authentication, >> I'm currently trying to pair CAS up with an XACML engine in order to get >> fine-grained authorization to take place before the HTTP request reaches the >> application. Together with a colleague, we've done a PoC on the matter and >> it seems to work without a hitch, BUT we're restricted to using >> CAS-generated SAML-tickets which are a bit unwieldy/expensive to push around >> in the system. >> >> I would much rather use regular CAS tickets and have the CAS client/filter >> provide the next filter in the chain (the XACML-PEP-filter in my case) with >> the attributes that are coded into the session, preferably as injected HTTP >> headers. This functionality is pretty standard in commercial Access >> Management products. >> >> One particular attribute I'm looking for, and unfortunately *can't* look up >> through the regular XACML architecture (using a PIP), is *which* >> authentication method the user used. I think CAS would really benefit from >> having the possibility to code in arbitrary attributes in the session when >> creating the TGT to be subsequently released to the application/next filter >> in line upon ticket validation. An example of such information available at >> the moment of authentication would be the user's IP address, authentication >> method used and user-agent; all of which could later be used for >> authorization, whether done in the XACML-PDP or through some other means. >> >> One of the things that made me promote CAS for this customer was that it is >> light-weight, but if I'm stuck to using SAML for attribute release (which is >> all well and good, but they are certainly not light-weight), then, I don't >> know... >> >> If the customer would want to use federation in the future and consume some >> other IdP's SAML tickets, I would convert that SAML ticket through a >> customized CAS authentication method to a regular CAS TGT when someone tries >> to access my customer's domain solely based on the fact that fully-fledged >> SAML tickets are signed and possibly encrypted which are simply too >> cumbersome to validate, decode and push around in the system an as >> authenticator. >> >> Anyway, what do you guys think? Please feel free to ask me questions if I've >> been unclear. >> >> /Daniel. >> >> On Tue, Jan 3, 2012 at 4:00 PM, Tillinghast, Andrew P. >> <atill...@conncoll.edu> wrote: >> >> Attribute release was a hot topic at the unconference and has again come up >> in the mailing list as a user need so I'd like to spark a developer >> discussion to see if we can do a point release to the CAS protocol and make >> attribute release official. >> >> It's actually covered in a few Jira entries but some examples: >> https://issues.jasig.org/browse/CAS-655 or >> https://issues.jasig.org/browse/CAS-738 >> >> I know this has been pushed off a few times as something CAS shouldn't be >> doing and/or should be handled through SAML, however some of the Official >> CAS clients, I know PHPCas for sure, already support the attribute release >> in the serviceValidation Response. >> >> If attribute release is only supported with the SAML >> https://wiki.jasig.org/display/CASUM/SAML+1.1 then it seems an encouragement >> for the end user to drop CAS and move to Shibboleth. >> >> At his point not making it officially part of the CAS protocol just leaves >> confusion over the proper formatting of the attribute response and creates a >> barrier that prevents some of the less savvy deployers from using a >> potential feature. >> >> <image.png> >> Andrew Tillinghast >> Sr. Web Developer >> atill...@conncoll.edu >> 270 Mohegan Avenue >> New London, CT 06320-4196 >> Ph:860 439-5265 Fax: 860 439-2871 >> P Think before you print >> CONFIDENTIALITY: This email (including any attachments) may contain >> confidential, proprietary and privileged information, and unauthorized >> disclosure or use is prohibited. If you received this email in error, please >> notify the sender and delete this email from your system. >> >> >> >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: droi...@gmail.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> dmitriy.kopyle...@gmail.com >> >> >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > brianxsav...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: ape...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
