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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
