In CAS server, each service validate can have its own ldap search and then put DN search results into service validate attributes (see person-directory)
In applications (CAS clients), check the attributes to know whether the user has rights or not and what rights he has. On Wed, 2011-04-20 at 10:52 +0200, Loïc Quentin wrote: > On 04/18/2011 06:28 PM, Shi Jinghai wrote: > > if authentication is same for all, you can add new service validates for > > your services for authorization purpose. for example, > > use /serviceAValidate for serviceA, /serviceBValidate for serviceB and > > etc. > > > I suppose I could use a validation url per service, and make user login > on a portal-like page… But I would have to use a DN reserved to CAS for > the login. > If a user logs in, I understand he will be given a ticket (or at least, > CAS will have a ticket for that user). If he laters attempts to log to > another service (serviceC), will that ticket be valid (ie, are two > tickets concerning the same user, but checked against LDAP using two > different DNs, differents? I can't really test it, because to do try > with two different DNs, I'd have to restart CAS, because of the > deployerConfigContext.xml, which will necessearily give two different > tickets…) ? > > But everything would be easier if I could access the referring > url/service in a class inherited from BindLdapAuthenticationHandler, > maybe using a getter method. I understand from Marvin's answer and the > protocol that this is a string parameter to the login/validation URL. > > On Mon, 2011-04-18 at 14:47 +0200, Loïc Quentin wrote: > >> On 04/18/2011 02:05 PM, Marvin Addison wrote: > >>>> The thing is, each service will use a specific DN > >>>> to bind to the LDAP server, and I can't possibly change that behavior. > >>> In strict terms this is case for any LDAP server -- you bind as the > >>> user's DN, which is different for every user. What's different about > >>> each DN? Do you allow anonymous searches, or require a (possibly > >>> different) manager DN for each branch of users? > >>> > >> I don't know much about LDAP, actually, so I'm not sure I'm using the > >> right words: > >> here's a little scenario to explain my situation: > >> User Bob wants to access service A. > >> Service A redirects user Bob to CAS Server, where user Bob enters his > >> credentials. > >> CAS server binds to LDAP using dn=serviceA,ou=serviceUsers,etc > >> Depending on the answer from LDAP, user Bob is granted access to service > >> A or not. > >> > >> Now, user Bib wants to access service B. > >> Service B redirects user Bib to CAS Server, where user Bib enters his > >> credentials. CAS server now has to bind to LDAP using > >> dn=serviceB,ou=serviceUsers,etc… > >> > >> Anonymous search is allowed, though, but authentication can't be done > >> using it, as it doesn't provide access to the password hash (if I get it > >> correctly). > >>>> But I still need to know the referring service. > >>> When a service requests a service ticket, it always does so via the > >>> service query string parameter. (See > >>> http://www.jasig.org/cas/protocol section 2.1.1.) That part is easy. > >> According to the protocol page, depending on how (login or > >> serviceValidation) CAS is called, there is a parameter passed to the > >> server that concerns the service needing authentication. If I could use > >> this, that would probably be perfect. > >>> There are two hard parts that follow: > >>> > >>> 1. How do you pass the service to the authentication handler? > >>> 2. What do you do when someone shows up to CAS without a service? > >>> > >>> CAS separates user authentication from service access as distinct > >>> operations, and you're conflating them in a way that will likely cause > >>> problems if you need a service and don't always have one. > >>> > >>> M > >>> > >> That's a good question, I'll have to discuss it with my boss (as I said, > >> I'm a trainee, and I don't really know the environment…). Maybe we could > >> use a default service value… > >> > >> Thanks for your help > >> > >> Loïc > >> > >> > > > > > > -- 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
