Grouper Users - Open Discussion List

[Chris Hyzer <>]

Sorry, Ive been on vacation...

Not really sure what you mean here, how is the lite UI tied to SQL subject 
sources?  You should be able to implement the subject API with a non SQL 
subject source if you like... buf if there is an easy way to get the data to 
SQL or LDAP that might be easier, up to you.  Let me know if you need more 
help :)

Thanks,
Chris



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

 
[mailto:]
 On Behalf Of Martin Feller
Sent: Thursday, February 17, 2011 12:15 PM
To: 

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

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