Just adding that this functionality will be supported by CAS 4.1 to a certain degree.
- Misagh > On Feb 11, 2015, at 3:16 PM, Waldbieser, Carl <[email protected]> wrote: > > Durga, > > CAS does authentication, not access control per se. There have been some > extensions to do service-based authorization for simple cases where access > control means "allowed to log in". > > Typically, the attribute release part of the CAS protocol (or the older SAML > validation protocol) allows you to send information like group memberships to > a service so the service can make the determination what authenticated users > are allowed to do. > > E.g. if CAS releases the following attributes to services for user "jdoe": > > memberOf: cn=app1,ou=groups,dc=example,dc=net > memberOf: cn=app3,ou=groups,dc=example,dc=net > > Then it might be reasonable for the services to respond like: > > App1: Welcome to Service #1, J. Doe! > App2: J. Doe, you are not allowed to use this app. > App3: Howdy J. Doe! Your last login was on 2015-02-01. > > The access control would be configured individually at each service. > > Thanks, > Carl > > ----- Original Message ----- > From: "Durga Prasad" <[email protected]> > To: [email protected] > Sent: Tuesday, February 10, 2015 9:28:43 PM > Subject: Re: [cas-user] How does CAS perform Sessioln Management? > > Hi Carl & Nancy, > > Kindly provide clarification for the below as well. > > If I have 3 Applications(App1, App2, App3) integrated to CAS > and I have Users U1, U2 & U3. > U1 should access App1, App2 but not App3. U2 should access App2, App3 but > not U1. > U3 should access App3, App1 but not App2. > > Is it possible to achieve the above criterion? Thanks in advance. > > Regards, > Durga Prasad > > > On Wed, Feb 11, 2015 at 10:01 AM, Durga Prasad <[email protected]> wrote: > >> Hi Carl, >> >> Superb explanation. Really articulated well. >> >> Thanks much. >> >> Regards, >> Prasad >> >> On Mon, Feb 9, 2015 at 10:33 PM, Waldbieser, Carl <[email protected]> >> wrote: >> >>> Prasad, >>> >>> 1. CAS uses a Ticket Granting cookie (TGC) to track the TGT issued during >>> authentication. >>> 2. CAS does not specifically protect from these attacks. However, if you >>> are using TLS as the transport layer for your services, that protects >>> againast MITM and replay attacks. Cross Site Request Forgery protection is >>> something each service provider must provide for itself where applicable. >>> 3. A TGT is a long-lived ticket that allows you to request service >>> tickets for specific services from CAS without having to re-present primary >>> credentials. A service ticket (ST) is a short-lived, one time use ticket >>> that a service provider validates with CAS in order to authenticate the >>> user. It is kind of like: >>> >>> user: CAS, please give me a one-time ST good for service "foo". >>> CAS : You don't have a TGT, so please provide me with credentials. >>> user: Here is my username and password. >>> CAS : Looks good. Here is a TGT that is good for 8 hours. >>> You can use that next time instead of having to type in your >>> credentials. >>> Also, here is the ST you asked for. It is only good for 10 >>> seconds. >>> user: Service "foo", here is a service ticket that identifies me. >>> foo : CAS, I received this ST-- could you validate it please? >>> CAS : This ST is good. It is for user "jdoe". >>> foo : User "jdoe", welcome to the "foo" service! >>> >>> Thanks, >>> Carl Waldbieser >>> ITS System Programmer >>> Lafayette College >>> >>> ----- Original Message ----- >>> From: "Durga Prasad" <[email protected]> >>> To: [email protected] >>> Sent: Sunday, February 8, 2015 10:35:43 AM >>> Subject: [cas-user] How does CAS perform Sessioln Management? >>> >>> Hi Folks, >>> >>> I have few doubts on CAS. >>> >>> 1. How does CAS maintain session between multiple aplications? >>> >>> 2. How CAS is secure from Man in the middle attack & Replay, CSRF attacks? >>> >>> 3. What is the differene between TGT & service ticket? >>> >>> Kindly clarify my doubts. >>> >>> Thanks in adavnce. >>> >>> Regards >>> Prasad >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >> >> > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
