Hi Joshua, The answer partly depends on what you mean by "federated authentication".
Most closed source proprietary SAML vendors mostly mean bi-lateral agreements with manual metadata exchange when they say "federated authN". If this is what your after, than yes CAS can do a reasonable job of that. CAS supports SAML 2.0 Web Browser SSO Profile ootb for Google Apps and the feature has been extended for other services. If you mean SAML federation with aggregated metadata like the InCommon Federation, and other SAML2 specific features your better of with something like Shibboleth or better yet CAS/Shib. If you simply mean cross domain WebSSO, then yes CAS alone does a fine job of that and can support attribute release for service authorization. This might also help: https://www.youtube.com/watch?v=sjcjVz3jLSk Best Bill On Sat, May 2, 2015 at 7:09 AM, Joshua Vecsei <j.vec...@gmx.de> wrote: > Hello, > > after doing some more research i got one more question about the CAS > implementation. > > Why CAS is not used for federated authentication? I know CAS does not > have something like a discovery service - but (theoretically) if I > implement a DS on my own and use this to forward to different > CAS-Servers, wouldn't that make CAS suitable for this use case too? > > ----------------- > What does the Discovery Service do? > > In Shibboleth version 1.3, the discovery service takes an AuthnRequest > message as input and, as a result of interaction with the user, forwards > this message on to the selected IdP. > (https://wiki.shibboleth.net/confluence/display/SHIB2/DiscoveryService) > ----------------- > > I am trying to understand why so many people prefer SAML over CAS. I > don't see (m)any advantages, except better support for authz ( bound > directly in apache ) and better support for custom attributes. > > Thanks in advance. > > > > Am 27.04.2015 um 01:18 schrieb Joshua Vecsei: > > My mistake all fine. > > I will keep those in mind. Thank you for your help. > > > > Regards > > > > > > Am 27.04.2015 um 01:17 schrieb Joshua Vecsei: > >> Thank you. The first link leads to a 404. > >> > >> > >> Am 26.04.2015 um 23:15 schrieb Misagh Moayyed: > >>> The next CAS release will have a few authz features built-in: > >>> > http://jasig.github.io/cas/development/installation/Service-Management.htm > >>> l#configure-service-access-strategy > >>> > >>> Or you could always use something like this: > >>> > https://github.com/Unicon/cas-addons/wiki/Role-Based-Services-Authorizatio > >>> n > >>> > >>> -----Original Message----- > >>> From: Joshua Vecsei [mailto:j.vec...@gmx.de] > >>> Sent: Sunday, April 26, 2015 4:09 AM > >>> To: cas-dev@lists.jasig.org > >>> Subject: Re: [cas-dev] CAS Authorization vs Shibboleth Authorization > >>> > >>> Hello, > >>> > >>> thank you! I will try this today. > >>> I think it is still a bit strange, that Shibboleth can say they support > >>> authorization ( > http://en.wikipedia.org/wiki/Shibboleth_%28Internet2%29 > >>> ) and CAS does not. Even if they to the same thing -> just supporthing > the > >>> service providers for making their own decissions about authorization > >>> based on the returned attributes ( roles/permissions ). > >>> > >>> > >>> > >>> > >>> > >>> Am 25.04.2015 um 16:32 schrieb Zico: > >>>> Joshua, > >>>> > >>>> You may try Gluu Server SSO system. It's open source and shibboleth, > >>>> CAS, OpenID Connect are also included there. They have community > >>>> edition rpm/deb, which you can try to install in your own VM. > >>>> http://www.gluu.org/docs/articles/gluu-server-ce/ > >>>> > >>>> On Sat, Apr 25, 2015 at 6:56 AM, Joshua Vecsei <j.vec...@gmx.de > >>>> <mailto:j.vec...@gmx.de>> wrote: > >>>> > >>>> Hello, > >>>> > >>>> I am working on a document to compare different Single Sign-On > >>> systems. > >>>> At the moment I am trying to find out what the pros and cons about > >>>> the CAS Authorization is, which means just sending additional > >>>> attributes, like permissions, to the service provider after > logging > >>>> in, and shibboleths way to request the permissions after logging > in. > >>>> As far as i understood shibboleth just does the same thing, just > >>>> sending attributes to the service provider as the SP requests > them. > >>>> > >>>> Why is this 'better' than using the CAS additional attributes to > >>>> authorize people, also regarding security issues? I am a little > bit > >>>> confused about the correct definition of a SSO system that > provides > >>>> authorization. > >>>> > >>>> Thanks in advance. > >>>> > >>>> Regards > >>>> Joshua > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> You are currently subscribed to cas-dev@lists.jasig.org > >>>> <mailto:cas-dev@lists.jasig.org> as: mailz...@gmail.com > >>>> <mailto:mailz...@gmail.com> > >>>> To unsubscribe, change settings or access archives, see > >>>> http://www.ja-sig.org/wiki/display/JSG/cas-dev > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Best, > >>>> Zico > >>>> > >>>> -- > >>>> You are currently subscribed to cas-dev@lists.jasig.org > >>>> <mailto:cas-dev@lists.jasig.org> as: j.vec...@gmx.de 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: > >>> mmoay...@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: > wgt...@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
