Difference between revisions of "CDO/Net4j Authentication"

From Eclipsepedia

< CDO
Jump to: navigation, search
(Client)
(CDO 3.0)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
In most enterprise application a user has to authentificate against the webserver, CDO application are not different in this aspect. So naturally CDO and Net4J provide a possibility to authentificate.
+
In most enterprise application a user has to authenticate against the webserver, [[CDO]] application are not different in this aspect. So naturally CDO and [[Net4j]] provide a possibility to authenticate. The source code shown in this section is part of a big [http://tom-eclipse-dev.blogspot.com/2008/09/exploring-new-technologies-part-of.html example project] exploiting [[RCP]] + [[EMF]] + [[Databinding]] features.
  
 
==Server==
 
==Server==
 
===Server configuration with cdo-server.xml===
 
===Server configuration with cdo-server.xml===
====Property-File based Authification====
+
====Property-File based Authentication====
If you are configuring your server using cdo-server.xml and providing authentification against a simple text file is as simple as uncommenting the following lines:
+
If you are configuring your server using cdo-server.xml and providing authentication against a simple text file is as simple as uncommenting the following lines:
  
<acceptor type="tcp" listenAddr="0.0.0.0" port="2036">
+
<source lang="xml">
  <negotiator type="challenge" description="/tmp/users.db"/>
+
<acceptor type="tcp" listenAddr="0.0.0.0" port="2036">
</acceptor>
+
  <negotiator type="challenge" description="/tmp/users.db"/>
 +
</acceptor>
 +
</source>
  
The value is the path to the user/password-File the authentification is done against. In this simple case the file is a Property-File and looks like this:
+
The value is the path to the user/password-File the authentication is done against. In this simple case the file is a Property-File and looks like this:
  
 
  tom=myverysecretpassword
 
  tom=myverysecretpassword
 +
 +
===CDO 3.0===
 +
Note that in CDO 3.0 we have an additional authentication mechanism per CDOSession (not on Net4j IConnector level). Using the IConnector based authentication is not the recommended way anymore.
 +
 +
The new CDOSession based approach involves setting an IUserManager into the ISessionManager of the IRepository '''before''' the repository is activated. On the client side you need to set an ICredentialsProvider into the CDOAuthenticator of the CDOSessionConfiguration '''before''' the session is opened. Both the IUserManager and the ICredentialsProvider can be the same implementations that you used with the Net4j based approach before.
 +
 +
CDO 3.0 does not yet have permission based security / Access Control List. But you might be able to implement your own using custom <tt>IRepository.ReadAccessHandler</tt> and <tt>IRepository.WriteAccessHandler</tt>.
 +
 +
===CDO 4.0===
 +
 +
See [https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075 Bugzilla 277075: Access Control system in CDO].
  
 
==Client==
 
==Client==
 
===IManagedContainer-Setup===
 
===IManagedContainer-Setup===
 
The standard code to retrieve the session in an IManagedContainer looks like this:
 
The standard code to retrieve the session in an IManagedContainer looks like this:
 
+
<source lang="java">
 +
public CDOSessionProvider {
 
   public CDOSession openSession(String id, String host, String port) {
 
   public CDOSession openSession(String id, String host, String port) {
 
     IConnector connector = TCPUtil.getConnector(IPluginContainer.INSTANCE, host + ":" + port );
 
     IConnector connector = TCPUtil.getConnector(IPluginContainer.INSTANCE, host + ":" + port );
Line 23: Line 37:
 
     configuration.setConnector(connector);
 
     configuration.setConnector(connector);
 
     configuration.setRepositoryName(id);
 
     configuration.setRepositoryName(id);
   
+
 
 
     return configuration.openSession();
 
     return configuration.openSession();
 
   }
 
   }
 +
}
 +
</source>
  
The authentification negotion has to be configured before the connection to the server is establish which happens here in the TCPUtil.getConnector()-method. So we somehow have to configure the system in between the call.
+
And use it in our code like this:
  
The first thing we need to do is to register a PostProcessor for the IPluginContainer.INSTANCE like this:
+
<source lang="java">
 +
CDOSessionProvider pv = new CDOSessionProvider();
 +
pv.openSession("MyRep","localhost","2036");
 +
</source>
  
  public CDOSession openSession(String id, String host, String port) {
+
The authentication negotiation has to be configured before the connection to the server is establish which happens here in the TCPUtil.getConnector()-method. So we somehow have to configure the system in between the call.
    IPluginContainer.INSTANCE.addPostProcessor(new IElementProcessor() { /* concrete impl see below */ })
+
  }
+
  
This ensures that we can enhance the configured connector and attach a so called INegotiator (in our case a special implementation for responses is available). The implementation to make this happen looks like this:
+
The only thing we need to do is to register a PostProcessor for the IPluginContainer.INSTANCE. This has to done only once for a IManagedContainer so the best part is a static block in the CDOSessionProvider.
  
  private class AuthElementProcessor implements IElementProcessor {
+
<source lang="java">
    private String username;
+
static {
    private String password;
+
  PasswordCredentialsProvider credentialsProvider = new PasswordCredentialsProvider("tom", "blabla");
   
+
  IPluginContainer.INSTANCE.addPostProcessor(new ConnectorCredentialsInjector("localhost:2036",credentialsProvider));
    public AuthElementProcessor(String username, String password) {
+
}
      this.username = username;
+
</source>
      this.password = password;
+
    }
+
   
+
    public Object process(IManagedContainer container,
+
                          String productGroup, String factoryType,
+
                          String description, Object element) {
+
      if( element instanceof InternalConnector ) {
+
        ResponseNegotiator rn = new ResponseNegotiator();
+
        ((InternalConnector)element).getConfig().setNegotiator(rn);
+
      }
+
     
+
      return element;
+
    }
+
  }
+
  
The last step is to configure a the ResponseNegotiator and provide PasswordCredentials for it used to do the real authentification.
+
Now your client authenticates against your CDO-Server and you'll receive a "org.eclipse.net4j.connector.ConnectorException" if you try to access session informations.
  
  if( element instanceof InternalConnector ) {
 
    ResponseNegotiator rn = new ResponseNegotiator();
 
    PasswordCredentialsProvider pw = new PasswordCredentialsProvider(new PasswordCredentials(username,password.toCharArray()));
 
    rn.setCredentialsProvider(pw);
 
    ((InternalConnector)element).getConfig().setNegotiator(rn);
 
  }
 
  
Now your client authentificates against your CDO-Server and you'll receive a "org.eclipse.net4j.connector.ConnectorException" if you try to access the session informations.
+
==Resources==
 +
# [https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075 Bugzilla 277075: Access Control system in CDO]
 +
# [http://www.eclipse.org/forums/index.php?t=msg&th=164519 Authentication OK, but what about authorization]
 +
# [http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg43230.html CDO authentication ]
 +
 
 +
[[Category:CDO]] [[Category:Net4j]] [[Category:EMF]] [[Category:Authentication]] [[Category:Security]] [[Category:Authorization]]

Latest revision as of 02:31, 26 May 2011

In most enterprise application a user has to authenticate against the webserver, CDO application are not different in this aspect. So naturally CDO and Net4j provide a possibility to authenticate. The source code shown in this section is part of a big example project exploiting RCP + EMF + Databinding features.

Contents

[edit] Server

[edit] Server configuration with cdo-server.xml

[edit] Property-File based Authentication

If you are configuring your server using cdo-server.xml and providing authentication against a simple text file is as simple as uncommenting the following lines:

<acceptor type="tcp" listenAddr="0.0.0.0" port="2036">
  <negotiator type="challenge" description="/tmp/users.db"/>
</acceptor>

The value is the path to the user/password-File the authentication is done against. In this simple case the file is a Property-File and looks like this:

tom=myverysecretpassword

[edit] CDO 3.0

Note that in CDO 3.0 we have an additional authentication mechanism per CDOSession (not on Net4j IConnector level). Using the IConnector based authentication is not the recommended way anymore.

The new CDOSession based approach involves setting an IUserManager into the ISessionManager of the IRepository before the repository is activated. On the client side you need to set an ICredentialsProvider into the CDOAuthenticator of the CDOSessionConfiguration before the session is opened. Both the IUserManager and the ICredentialsProvider can be the same implementations that you used with the Net4j based approach before.

CDO 3.0 does not yet have permission based security / Access Control List. But you might be able to implement your own using custom IRepository.ReadAccessHandler and IRepository.WriteAccessHandler.

[edit] CDO 4.0

See Bugzilla 277075: Access Control system in CDO.

[edit] Client

[edit] IManagedContainer-Setup

The standard code to retrieve the session in an IManagedContainer looks like this:

public CDOSessionProvider {
  public CDOSession openSession(String id, String host, String port) {
    IConnector connector = TCPUtil.getConnector(IPluginContainer.INSTANCE, host + ":" + port );
    CDOSessionConfiguration configuration = CDOUtil.createSessionConfiguration();
    configuration.setConnector(connector);
    configuration.setRepositoryName(id);
 
    return configuration.openSession();
  }
}

And use it in our code like this:

CDOSessionProvider pv = new CDOSessionProvider();
pv.openSession("MyRep","localhost","2036");

The authentication negotiation has to be configured before the connection to the server is establish which happens here in the TCPUtil.getConnector()-method. So we somehow have to configure the system in between the call.

The only thing we need to do is to register a PostProcessor for the IPluginContainer.INSTANCE. This has to done only once for a IManagedContainer so the best part is a static block in the CDOSessionProvider.

static {
  PasswordCredentialsProvider credentialsProvider = new PasswordCredentialsProvider("tom", "blabla");
  IPluginContainer.INSTANCE.addPostProcessor(new ConnectorCredentialsInjector("localhost:2036",credentialsProvider));
}

Now your client authenticates against your CDO-Server and you'll receive a "org.eclipse.net4j.connector.ConnectorException" if you try to access session informations.


[edit] Resources

  1. Bugzilla 277075: Access Control system in CDO
  2. Authentication OK, but what about authorization
  3. CDO authentication