|
| Re: Security with JAAS [message #738934 is a reply to message #735946] |
Sun, 16 October 2011 23:40   |
 Daniel Wiehl
Messages: 1
Registered: May 2016 |
Junior Member |
|
|
Hi Bertin
Scout security actually relies on concepts of the JAAS framework by representing the source of a request as a subject with principals associated. In turn, any action is performed on behalf of that subject in a respective doAs-call.
Instead of using the core JAAS classes for authentication (LoginContext, LoginModule, CallbackHandler and Callback), we authenticate users directly in so called SecurityFilters. Those filters are chainable, meaning that you might have several filters knowing of how to authenticate user credentials against database (DataSourceSecurityFilter), LDAP directory (LDAPSecurityFilter) or whatever you like. Those filters are registered as an extension to the extension point 'org.eclipse.scout.http.servletfilter.filters'. If a filter can authenticate the user successfully, the request is passed within a doAs call to the endpoint servlet (ServiceTunnelServlet) to dispatch the call to the requested OSGi service.
Because we are not using the LoginContext for authentication and do not want to be based on the static policy configuration files for principal-based granting (Policy API), permission loading is done by Scout AccessControlService. There are gathered all the permissions that belong to the authenticated subject and are maintained in Scout AccessControlStore. In consequence, authorization cannot be delegated to JAAS AccessController, but is done in a very convenient way by Scout AccessControlService itself. For more information on that topic of how to load permissions and do access control checks, please refer to the forum post on http://www.eclipse.org/forums/index.php/t/243966/.
Let us have a look on how the system prompts for authentication.
First you have to know, that all code on client is run within a doAs call with the user's account name as subject. By default, authentication is only triggered by calling the backend. That means that if you have a standalone client application without a server running, you are never prompted for authentication.
So when doing your first backend call, a connection to the server is established. In the application's life cycle, this typically occurs if initializing the client session which is quite the first thing done. Thereby, the security filter on server side intercepts the call. Because no subject is associated yet, a 401 Unauthorized error code is sent back to the client. On client side, before being propagated back to the caller, this 401 is intercepted by the installed net authenticator. By default, the installed authenticator first looks in the Eclipse secure preference store for credentials. If not available, a login dialog is presented to the user to enter username and password. In turn, those are sent back to the server to continue authentication.
Please note, that the authenticator mechanism can be installed in your Swing application by calling NetActivator.install().
@Override
protected Object startInSubject(IApplicationContext context) throws Exception {
NetActivator.install();
return super.startInSubject(context);
}
Thereby, the default Scout authenticator InternalNetAuthenticator is installed. This can be easily overwritten by registering an OSGi service with the name java.net.Authenticator and a ranking higher than -2. Alternatively, you can register an extension to the Eclipse extension point org.eclipse.core.net.authenticator that contains your custom java.net.Authenticator.
If you have any further questions, please feel free and let us know.
[Updated on: Mon, 17 October 2011 05:44] by Moderator Report message to a moderator |
|
|
|
Powered by
FUDForum. Page generated in 0.03138 seconds
] 
Search
Help
Register
Login
Home
