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.

Thanks!

-- 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
relational
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.

Thanks,

Martin

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.

Thanks,

Martin

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>
<filter-name>Your Filter</filter-name>
<filter-class>com.path.whatever.YourFilter</filter-class>
</filter>


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-mapping>
<filter-name>Your Filter</filter-name>
<url-pattern>*</url-pattern>
</filter-mapping>

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


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

import java.io.IOException;

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
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
[mailto:]
Sent: Monday, February 14, 2011 4:44 PM
To: Chris Hyzer
Cc:

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

Thanks,

Martin

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

Thanks,
Chris

-----Original Message-----
From:


[mailto:]
On Behalf Of Martin Feller
Sent: Monday, February 14, 2011 4:27 PM
To:

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

Hi,

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
here: https://spaces.internet2.edu/display/Grouper/Authentication

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?

Thanks!

Martin


Archive powered by MHonArc 2.6.16.

Top of Page