Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] lite ui and authentication mechanism

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] lite ui and authentication mechanism

Chronological Thread 
  • From: Shilen Patel <>
  • To: Martin Feller <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] lite ui and authentication mechanism
  • Date: Fri, 18 Feb 2011 15:40:50 -0500

You could implement your own source. By default, Grouper uses edu.internet2.middleware.grouper.subj.GrouperJdbcSourceAdapter and it also comes with an LDAP source adapter. But you could create your own and add the configuration to sources.xml to make SubjectFinder query your source.


-- Shilen

On 2/17/11 12:15 PM, Martin Feller wrote:
I could probably do something similar to the LDAP provisioner, that
periodically scans the real subject source and dumps the subjects into a
database, which is then used by the lite UI, but that's a level of
indirection that i'd like to avoid if possible.

On 2/17/11 11:11 AM, Martin Feller wrote:
Ok, this works btw.
Now, similar question... I assume it doesn't work for the lite UI because it
looks hard-coded, but is there a way to configure a custom SubjectFinder?
I need to be able to get a subject by other means than a relational database,
like using Cassandra, or, and this is my use-case, by a call to some remote
RESTful resource.



On 2/14/11 4:44 PM, Martin Feller wrote:
Actually, the filter order shouldn't even matter...

On 2/14/11 4:26 PM, Martin Feller wrote:
Ah, request.setAttribute("REMOTE_USER", username), I didn't think of that
one. If this filter is run before the existing filter it should work out.
And yes, the cookie information is signed, so messing with the cookie
shouldn't work.



On 2/14/11 4:00 PM, Chris Hyzer wrote:
True, we should add that capability... I assume you have a way so that
nefarious users don't set their cookie value to act as other users... :)

This is what you need to do:

1. in the web.xml declare your filter:

<filter-name>Your Filter</filter-name>

Note, this part Im not sure about... I think you can just protect everything
(*), though you could pick and choose URL patterns like the existing config
does... Note, this part has to be above the existing filter mappings in
the web.xml so it is outside the other filters.

<filter-name>Your Filter</filter-name>

2. Make a Java class called that, and do this: here is a simple example

* @author mchyzer
* $Id:,v 1.3 2009-11-25 20:01:26 mchyzer Exp $
package com.path.whatever;


import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;

public class YourFilter implements Filter {

* @see javax.servlet.Filter#destroy()
public void destroy() {

* @see javax.servlet.Filter#doFilter(javax.servlet.ServletRequest,
javax.servlet.ServletResponse, javax.servlet.FilterChain)
public void doFilter(ServletRequest req, ServletResponse res, FilterChain
throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest)req;

String username = cookieValue(request, "someCookieName");

//do some decryption or something? :)

request.setAttribute("REMOTE_USER", username);

filterChain.doFilter(request, res);

* get a cookie value by name, null if not there
* @param httpServletRequest
* @param name
* @return the cookie value or null if not there
public static String cookieValue(HttpServletRequest httpServletRequest,
String name) {
Cookie cookie = findCookie(httpServletRequest, name);
return cookie == null ? null : cookie.getValue();

* find a cookie or null if cant find
* @param httpServletRequest
* @param name
* @return the cookie or null if not found
public static Cookie findCookie(HttpServletRequest httpServletRequest,
String name) {
//no nulls
if (name != null) {
Cookie[] cookies = httpServletRequest.getCookies();
//go through all cookies and find the cookie by name
int cookiesLength = cookies == null ? 0 : cookies.length;
for (int i=0;i<cookiesLength;i++) {
if (name.equals(cookies[i].getName())) {
return cookies[i];
return null;

* @see javax.servlet.Filter#init(javax.servlet.FilterConfig)
public void init(FilterConfig arg0) throws ServletException {


-----Original Message-----
From: Martin Feller
Sent: Monday, February 14, 2011 4:44 PM
To: Chris Hyzer

Subject: Re: [grouper-users] lite ui and authentication mechanism

I try to integrate the light UI into an existing webpage. After logging into
that webpage information about
the user (like username) is stored in a cookie. I don't want an additional
basic authentication step when the group
management page is rendered, but rather have the Grouper UI servlet use the
information from the cookie to get the user id.
All works fine, I see the cookies, but I think I need to do changes in the
filter code to accomplish this.
Having a declarative option, like in grouper-ws, would be cleaner, I guess



On 2/14/11 3:28 PM, Chris Hyzer wrote:
What authentication mechanism do you want to use?


-----Original Message-----

On Behalf Of Martin Feller
Sent: Monday, February 14, 2011 4:27 PM

Subject: [grouper-users] lite ui and authentication mechanism


Can somebody please confirm the following?

I was trying to write a custom authentication mechanism and hook it into the
Prototype Lite UI, as described

But I think this won't work, because the mechanisms described there are only
for grouper-ws.
The lite UI servlet that handles the AJAX calls from grouper.html, or rather
the service logic classes used by the
lite UI servlet, call a static method of the GrouperUI filter to get the
remote user though.

So there's no configuration-only way to change the authentication mechanism
for this UI, right?



Archive powered by MHonArc 2.6.16.

Top of Page