> > 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. >
The Shib IdP can return attributes in the same transaction as authentication, depending on the kind of request sent by the SP. > As far as i understood shibboleth just does the same thing, just sending > attributes to the service provider as the SP requests them. > That's the AttributeAuthority functionality. SAML1 had a limitation that required querying for attributes at a separate endpoint, thus 2 transactions were required. The SAML2 spec allows returning an authentication statement and attribute statement in a single SAML response message. In my experience as a Shib IdP operator, this mode is most common nowadays. > Why is this 'better' than using the CAS additional attributes to > authorize people, also regarding security issues? It's not better, just different. I tend to think of CAS as the best solution for institutional SSO, while Shib is _the_ choice for federated SSO. > I am a little bit > confused about the correct definition of a SSO system that provides > authorization. > It may be helpful to clarify that neither CAS nor Shib is an authorization system. Jasig CAS has grown some authorization capabilities over time, but it's not well suited for enforcing centralized authorization policy. It's better to consider both systems as facilitating decentralized authorization policy by releasing attributes in support of authorization decisions. The use case for Shib in particular is fundamentally decentralized due to the nature of federated SSO. M -- 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
