Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » DataSourceSecurityFilter and Client/Serversession
DataSourceSecurityFilter and Client/Serversession [message #1606943] Sun, 08 February 2015 14:30 Go to next message
Peter Pfeifer is currently offline Peter PfeiferFriend
Messages: 193
Registered: November 2014
Senior Member

Hello there,

I'm wondering if it's possible to select more than one column in the DataSourceSecurityFilter#selectUserPass statement and then the Client/Serversession is populated with the columns form the SELECT statement.

E.g. from the
DataSourceSecurityFilter#selectUserPass=SELECT LOWER(username), id, countyid, seclevel FROM Users WHERE LOWER(username)=? AND PASSWORD=?


statement something like this is possible:

Long countyID = (Long) ClientSession.get().getSharedVariableMap().get("countyid");
Integer secLevel = (Integer) ClientSession.get().getSharedVariableMap().get("seclevel");
Long userId = (Long) ClientSession.get().getSharedVariableMap().get("id");


Would this make sense in a default implementation of DataSourceSecurityFilter or is this too specific.

If it is too specific, can someone give me a hint how I can populate the Client/Serversession on my own?

Thanks

Peter
Re: DataSourceSecurityFilter and Client/Serversession [message #1608285 is a reply to message #1606943] Mon, 09 February 2015 12:04 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
Peter Pfeifer wrote on Sun, 08 February 2015 15:30
Would this make sense in a default implementation of DataSourceSecurityFilter or is this too specific.

If it is too specific, can someone give me a hint how I can populate the Client/Serversession on my own?


I do not know DataSourceSerurityFilter very well and I can't tell if you can extend it as you have described.

Check this discussion: Actions upon user login in Client and Server

In execLoadSession() instead of the line "//Do something to initialize the value" you can connect to a database. (using SQL.selectInto(..) like everywhere).
Re: DataSourceSecurityFilter and Client/Serversession [message #1608320 is a reply to message #1608285] Mon, 09 February 2015 12:33 Go to previous messageGo to next message
Peter Pfeifer is currently offline Peter PfeiferFriend
Messages: 193
Registered: November 2014
Senior Member

Jeremie Bresson wrote on Mon, 09 February 2015 12:04
In execLoadSession() instead of the line "//Do something to initialize the value" you can connect to a database. (using SQL.selectInto(..) like everywhere).


Yes this would be possible,. But this would be another round trip to the server/database. And since I can retrieve all the values with one statement it would make perfectly sense to use the retrieved values.

As a rule of thumb I want to avoid as many round trips as possible.

The same is problems occur when working with collections and SQL.update/delete...

When providing a list as binding variable to the SQL statements, for every entry in the collection a single sql statement is generated and sent to the server instead of using the IN-clause of the RDBMS and transfer a list of the collection values... Because then just one SQL statment has to be processed instead of n statements depending on the collection size.

This is something I think could need some tweaking.

Regards, Peter
Re: DataSourceSecurityFilter and Client/Serversession [message #1608801 is a reply to message #1608320] Mon, 09 February 2015 19:28 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
I agree with you about the database round trips, but I have not enough knowledge to help you on this precise point.

I never did any profiling or benchmark, about the impact of the "at least database round-trips as possible" optimization. I think it also depends on the database engine.

For example I know that oracle database has a statement cache where the execution plan of the last X queries are stored. I do not think that having 1 statement with N set of binds or a statemetn with one set of bind called N times will really matters.

Each improvements you suggest in this area will taken into consideration, feel free to propose some changes.

I know there is already the notion of batch processing of the scout binds. I use in the OUT-direction (from DB to Scout) to populate table data or list of beans. I think there is also something in the IN-direction (from Scout to the db), but I should look into the code to be sure.
Re: DataSourceSecurityFilter and Client/Serversession [message #1609629 is a reply to message #1606943] Tue, 10 February 2015 08:30 Go to previous messageGo to next message
Florian Widmer is currently offline Florian WidmerFriend
Messages: 8
Registered: March 2012
Junior Member
I did something similar with an older version of scout but it might still work. You will have to implement your own security filter. either a subtype of DataSource or directly AbstractChainable.
The method negotiate(req, resp, holder) passes a PrincipalHolder around.
protected int negotiate(HttpServletRequest req, HttpServletResponse resp, final PrincipalHolder holder) throws IOException, ServletException {
  //Fill your principal and add it to the holder
  return STATUS_CONTINUE_WITH_PRINCIPAL;
 }

Implement your own subtype of Principal and fill it up in your implementation of the negotiate method.
public class MyPrincipal extends SimplePrincipal {
    
    private AuthenticationBean autheticationBean;

    public MyPrincipal(String name) {
        super(name);
    }

    public MyPrincipal(AuthenticationBean bean) {
        super(bean.getUserName());
        this.autheticationBean = bean;
    }

    public AuthenticationBean getAutheticationBean() {
        return autheticationBean;
    }

    public void setAutheticationBean(AuthenticationBean autheticationBean) {
        this.autheticationBean = autheticationBean;
    }

}

Once you are in the ServerSession (execInitSession) you can access the set of principals by calling
Subject.getSubject(AccessController.getContext()).getPrincipals();

and retrieve the values that you set earlier.

However, I also think one more trip to the database does not hurt at this point. My solution arose from an authentication that is based on single sign on based on an encrypted URL.
Re: DataSourceSecurityFilter and Client/Serversession [message #1609774 is a reply to message #1609629] Tue, 10 February 2015 10:30 Go to previous messageGo to next message
Peter Pfeifer is currently offline Peter PfeiferFriend
Messages: 193
Registered: November 2014
Senior Member

Hello Florian,
thanks for the reply.

Florian Widmer wrote on Tue, 10 February 2015 08:30
My solution arose from an authentication that is based on single sign on based on an encrypted URL.


This is something I will have to implement too. At least something similar. My application will be called from another webpage. Some encoded URL. Based on this URL I will call a webservice from the calling web application in order to get user credientials and so on.

Did you set a special URL Filter as well?

Peter
Re: DataSourceSecurityFilter and Client/Serversession [message #1609910 is a reply to message #1609774] Tue, 10 February 2015 12:23 Go to previous messageGo to next message
Florian Widmer is currently offline Florian WidmerFriend
Messages: 8
Registered: March 2012
Junior Member
Peter Pfeifer wrote on Tue, 10 February 2015 05:30

Did you set a special URL Filter as well?


For our implementation, we use a URL parameter containing an encrypted token. Within the token the user credentials are encrypted. In principle, we could verify the token against the service where it was generated, but we don't (knowledge of the symmetrical encryption password is enough). So all we do is decrypt the token and pass the username and other information along using the principal. If the token is not valid, we reject the request.

The implementation inherits from AbstractChainableSecurityFilter directly without any additional security filters.
Re: DataSourceSecurityFilter and Client/Serversession [message #1609968 is a reply to message #1609910] Tue, 10 February 2015 13:12 Go to previous messageGo to next message
Peter Pfeifer is currently offline Peter PfeiferFriend
Messages: 193
Registered: November 2014
Senior Member

Would it be possible, that you show me your code snippets and configuration?

Peter
Re: DataSourceSecurityFilter and Client/Serversession [message #1610069 is a reply to message #1609968] Tue, 10 February 2015 14:32 Go to previous messageGo to next message
Florian Widmer is currently offline Florian WidmerFriend
Messages: 8
Registered: March 2012
Junior Member
Hi Peter,

I can't go into detail about the encryption but here's the servlet filter in a somewhat abbreviated form. The retrieval should work as i described above as well as the Principal.

Unfortunately this is with a quite antiquated version of scout so I cant guarantee that all the API and plugin.xml references are still the same.

I think the detail to notice is that the extension point is the equinox one and not from scout.

Cheers,

Florian

MyServletFilter
public class MyServletFilter extends AbstractChainableSecurityFilter{
  
 (...) //fields and some methods to check timestamp, translate internal state
    protected enum AuthenticationState {
        USER_AUTHENTICATED, ACCESS_DENIED, SERVER_ERROR
    }
    @Override
    protected int negotiate(HttpServletRequest req, HttpServletResponse resp, final PrincipalHolder holder) throws IOException, ServletException {
        final String token = req.getParameter(TOKEN_STRING);
        AuthenticationState result = authenticate(holder, token);
        return getFinalResult(result, req, resp); //translation from internal states to integer as expected by API
    }

    private AuthenticationState authenticate(final PrincipalHolder holder, final String token) {
        if (token == null) {
            return AuthenticationState.ACCESS_DENIED;
        } else {
            return authenticateUsingToken(token, holder);
        }
    }

    private AuthenticationState authenticateUsingToken(String token, PrincipalHolder holder) {
        AuthenticationBean bean;
        try {
            bean = extractAuthenticationBean(token);
        } catch (MyException e) {
            return AuthenticationState.SERVER_ERROR;
        }
        if (checkTimestamp(bean)) {
            // Get username and create principal
            if (!StringUtility.isEmpty(bean.getUserName())) {
                holder.setPrincipal(new MyPrincipal(bean));
                return AuthenticationState.USER_AUTHENTICATED;
            }
        }
        return AuthenticationState.ACCESS_DENIED;
    }
}


Plugin.xml

    <extension point="org.eclipse.equinox.http.registry.filters">
      <filter alias="/app" class="package.MyServletFilter">
            <init-param name="filter-priority" value="100" />
        </filter>


config.ini

package.MyServletFilter#realm=REALM
package.MyServletFilter#active=true



Re: DataSourceSecurityFilter and Client/Serversession [message #1611056 is a reply to message #1610069] Wed, 11 February 2015 05:53 Go to previous message
Peter Pfeifer is currently offline Peter PfeiferFriend
Messages: 193
Registered: November 2014
Senior Member

Thanks Florian,
that helps me a lot. I'll give this a try on the weekend.

Peter
Previous Topic:AbstractTableFieldBeanData#getRows() is returning an Array.
Next Topic:Help with RAP error!
Goto Forum:
  


Current Time: Sat Dec 16 15:13:58 GMT 2017

Powered by FUDForum. Page generated in 0.01963 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software