Let me give an example to be more clear: Suppose we have CMA as a default authentication module and it is mapped to any path (as alternative to specific URL like /cm/login ).
1. New user (I mean that hadn't been saved in ESME DB yet) has been already authenticated somewere in external app (may be in portal). Then he tries to access ESME with some kind of token (or certificate). 2. CMA module checks that it's authenticated user, gets his username, possibly finds additional attributes in LDAP and subsequently saves these data to ESME DB and logs user in. Now it has to redirect user to the requested (or root) path. 3. But due to CMA module is mapped on *any* path, it's called again. Module checks that it is the same authenticated user and this time retreives his details from ESBE DB and log him again. After that it (second time) redirects user to requested path. 4. For the same reasons that were specified in p.3 CMA module is called again and performs the same actions. etc When CMA auth module is mapped to specific URL it's possible to redirect (already logged in) user to the requested path (which is not served by the module). But what should module do in this case? Vladimir 2011/10/13 Richard Hirsch <[email protected]> > I think it depends on the scenario. In some cases, you want multiple > login possibilities (username/password + OpenID), other time you just > want one (CMA). We should be flexible enough to support both > variations. > > Can we do this with properties? > > D. > > On Wed, Oct 12, 2011 at 12:17 AM, Vladimir Ivanov <[email protected]> > wrote: > > At the moment, all auth modules are mapped to specific URL in order to > hook > > in and create new / retreive existing user to log in into app. Now > following > > questions come to my mind: > > > > What path should container auth module be mapped to? *Any* path (_)? Now > due > > to authentication takes place externally (by container), while it's > possible > > to check if user is authorized and get username, in general I'm not able > to > > figure out whether module's logic have to be executed for every specific > > request (after user has been redirected to requested path). > > > > Any ideas? > > > > Vladimir > > > > 2011/10/8 Richard Hirsch <[email protected]> > > > >> > >> How would I configure esme to go straight to the > >> container-authentication without having to go to " > >> http://your_host_port_and_context/cm/login"; . I type in > >> "http://your_host_port_and_context"; and am sent automatically to the > >> container-based authenication. Assuming that is not Tomcat or > >> jetty-based but another site and thus, I don't have to type in > >> username/password but use something else, like a token. > >> > >> Thanks, > >> > >> D. > >> > >> > >> > >> On Sat, Oct 8, 2011 at 3:06 AM, Vladimir Ivanov <[email protected]> > >> wrote: > >> > Hi guys, > >> > > >> > List of all possible roles is taken from default property file as a > value > >> of > >> > role_list property. hsr.isUserInRole(_) call checks whether current > user > >> has > >> > role to access this resource. If we talk about container-managed > >> > authentication in Java EE web application, then mappings between URLs > and > >> > roles are specified in web.xml. In turn, mappings between users > (groups) > >> and > >> > roles are container-specific. It might be a property/xml file like > >> > jetty-login.properties or tomcat-users.xml (as far as I remember we > >> decided > >> > not to add these files in repository, but they should have been > attached > >> to > >> > corresponding issue in JIRA) or web container might be configured to > use > >> an > >> > LDAP server. All neccessary configuration steps are described in blog > >> entry. > >> > > >> > So most probably the reason of this problem is that mapping between > users > >> > and roles is not configured properly. > >> > > >> > Vladimir > >> > > >> > > >> > 2011/10/5 Richard Hirsch <[email protected]> > >> > > >> >> Thanks > >> >> > >> >> D. > >> >> > >> >> On Wed, Oct 5, 2011 at 10:45 AM, Ethan Jewett <[email protected]> > >> wrote: > >> >> > Hi Dick, > >> >> > > >> >> > Maybe change rolesToCheck to something like: > >> >> > > >> >> > val rolesToCheck = Props.get("role_list") match { > >> >> > case Full(s) => { debug("The following roles were found in > >> >> > role_list: %s".format(s)) > >> >> > s.split(',').toList } > >> >> > case _ => { debug("No roles found in role_list.") > >> >> > Nil } > >> >> > } > >> >> > > >> >> > No idea if that will actually compile, but it looks more or less > >> right. > >> >> > > >> >> > Cheers, > >> >> > Ethan > >> >> > > >> >> > On Tue, Oct 4, 2011 at 5:28 AM, Richard Hirsch < > [email protected] > >> > > >> >> wrote: > >> >> >> Hi, > >> >> >> > >> >> >> Right now, I'm trying to get container-based authentication to > work > >> >> >> and I'm having a problem with the roles in UserAuth.scala. I know > >> that > >> >> >> Vladimir is still on vacation but I thought someone else might be > >> able > >> >> >> to help me. > >> >> >> > >> >> >> The code is here: > >> >> >> > >> >> >> val currentRoles = > >> rolesToCheck.filter(hsr.isUserInRole(_)) > >> >> >> debug("User from HTTP Request: %s has following > >> >> >> roles=%s".format(username, currentRoles)) > >> >> >> if(currentRoles.size == 0) { > >> >> >> debug("No roles have been found") > >> >> >> S.error(S.?("base_user_err_unknown_creds")) > >> >> >> > >> >> >> The size of currentRoles is always 0 and I'm trying to trace why. > >> >> >> > >> >> >> How could I debug/trace all the values to rolesToCheck (line 290) > ? > >> >> >> > >> >> >> Thanks > >> >> >> > >> >> >> D. > >> >> >> > >> >> > > >> >> > >> > > >> > > >> > > >> > -- > >> > Best Regards, > >> > Vladimir Ivanov > >> > > >> > > > > > > > > -- > > Best Regards, > > Vladimir Ivanov > > > -- Best Regards, Vladimir Ivanov
