Eclipse Community Forums: EMF » CDO authentication

Home » Modeling » EMF » CDO authentication

Wed, 19 August 2009 12:37

Eclipse User

As far as we know there are two ways of starting a CDO server:

1) create a cdo-server.xml configuration file and start a
org.eclipse.emf.cdo.server.product specifying the parameter net4j.config

2) starting it programmatically (using IManagedContainer, IStore,
IRepository and so on)

We adopted the solution 2) just because we need to register a custom query
handler, with the following line:
container.registerFactory(new CustomQueryHandlerFactory(
dbConnectionProvider));

now we would like to add authentication features to our server, so the
question is: how can we programmatically add this feature (we didn't find
examples, just found how to do it with cdo-server.xml, with challenge
negotiator)?

Alternatively, is it possible to configure the cdo-server.xml in order to
use a custom query framework?

Thanks in advance

Vincenzo Caselli

Re: CDO authentication [message #481400 is a reply to message #481114]

Thu, 20 August 2009 15:52

Eclipse User

Vincenzo,

Using the IConnector based authentication is not the recommended way
anymore. The new CDOSession based approach envolves settingan
IUserManager into the ISessionManager of the IRepository. Unfortunately
(IIRC) you currently need to use internal code to do this. I'll change
this if you filea bugzilla. On the client side you need to set an
ICredentialsProvider into the CDOAuthenticator of the
CDOSessionConfiguration. Bothe the IUserManager and the
ICredentialsProvider can be the same implementations that you used with
the Net4j based approach before.

I hope that helps ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com

Vincenzo Caselli schrieb:
> As far as we know there are two ways of starting a CDO server:
>
> 1) create a cdo-server.xml configuration file and start a
> org.eclipse.emf.cdo.server.product specifying the parameter net4j.config
>
> 2) starting it programmatically (using IManagedContainer, IStore,
> IRepository and so on)
>
> We adopted the solution 2) just because we need to register a custom
> query handler, with the following line:
> container.registerFactory(new CustomQueryHandlerFactory(
> dbConnectionProvider));
>
> now we would like to add authentication features to our server, so the
> question is: how can we programmatically add this feature (we didn't
> find examples, just found how to do it with cdo-server.xml, with
> challenge negotiator)?
>
> Alternatively, is it possible to configure the cdo-server.xml in order
> to use a custom query framework?
>
> Thanks in advance
>
> Vincenzo Caselli
>

Re: CDO authentication [message #503533 is a reply to message #481400]

Mon, 14 December 2009 10:55

Eclipse User

Hi Eike,

can you give me a short sketch how to add my own IUserManager to the ISessionManager of the repository? It is requiered to create my own Negotiators together with a NegotiatorFactory and introduce them via a extension point? Sorry, this is just a guess. Actually I don't have a idear to get started with this.

Of cause, if anybody else know how to do this, she or he can answer me as well. This would be really nice.

Thanks a lot for your help.
Regards,
René

Re: CDO authentication [message #503559 is a reply to message #503533]

Mon, 14 December 2009 12:01

Eclipse User

This is a multi-part message in MIME format.
--------------020202070909090109020607
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi René,

Comments below...

René schrieb:
> Hi Eike,
>
> can you give me a short sketch how to add my own IUserManager to the
> ISessionManager of the repository?
I'm not very happy with the way to customize the server-side components
and I hope that I can introduce a better mechanism in 3.0. Our test
framework shows how to do it currently:

| *protected *InternalRepository createRepository(String name)
{
IStore store = createStore(name);
Map<String, String> props = getRepositoryProperties();
InternalRepository repository = (InternalRepository)CDOServerUtil.createRepository(name, store, props);
InternalCDORevisionManager revisionManager = getTestRevisionManager();
*if *(revisionManager != *null*)
{
repository.setRevisionManager(revisionManager);
}

IUserManager userManager = getTestUserManager();
_ * **if (userManager != null)
{
InternalSessionManager sessionManager = new SessionManager();
sessionManager.setUserManager(userManager);
repository.setSessionManager(sessionManager);
}
*_
IQueryHandlerProvider queryHandlerProvider = getTestQueryHandlerProvider();
*if *(queryHandlerProvider != *null*)
{
repository.setQueryHandlerProvider(queryHandlerProvider);
}

*return *repository;
}|

> It is requiered to create my own Negotiators together with a
> NegotiatorFactory and introduce them via a extension point?
No, on the client-side you need to provide a credentials provider (see
SessionTest.java, too):

| *public *CDOSession openSession(String repositoryName)
{
CDOSessionConfiguration configuration = createSessionConfiguration(repositoryName);
_* *__*configuration.getAuthenticator().setCredentialsProvider( getTestCredentialsProvider());
*_
CDOSession session = configuration.openSession();
configureSession(session);
session.addListener(sessionListener);

*synchronized *(sessions)
{
sessions.add(session);
}

*return *session;
}|

Does this help?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> Sorry, this is just a guess. Actually I don't have a idear to get
> started with this.
> Of cause, if anybody else know how to do this, she or he can answer me
> as well. This would be really nice.
>
> Thanks a lot for your help.
> Regards,
> René

--------------020202070909090109020607
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi René, 
 
Comments below... 
 
 
René schrieb:
<blockquote cite="mid:hg5n5v$bev$1@build.eclipse.org" type="cite">Hi
Eike,
 
 
can you give me a short sketch how to add my own IUserManager to the
ISessionManager of the repository? </blockquote>
I'm not very happy with the way to customize the server-side components
and I hope that I can introduce a better mechanism in 3.0. Our test
framework shows how to do it currently: 
 
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">



<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code> protected InternalRepository createRepository(String name) 
 { 
 IStore store = createStore(name); 
 Map<String, String> props = getRepositoryP roperties (); 
 InternalRepository repository = (InternalRepository)CDOServerUtil.createRepository(name, store, props); 
 InternalCDORevisionManager revisionManager = getTestRevis ionManager (); 
 if (revisionManager != null) 
 { 
 repository.setRevisionManager(revisionManager); 
 } 
 
 IUserManager userManager = getTestUserManager (); 
 if (userManager != null) 
 { 
 InternalSessionManager sessionManager = new SessionManager(); 
 sessionManager.setUserManager(userManager); 
 repository.setSessionManager(sessionManager); 
 } 

 
 IQueryHandlerProvider queryHandlerProvider = getTestQuery HandlerProvider (); 
 if (queryHandlerProvider != null) 
 { 
 repository.setQueryHandlerProvider (queryHandlerProvider); 
 } 
 
 return repository; 
 }</code>
</td>
 </tr>
</tbody>
</table>
</div>

 
<blockquote cite="mid:hg5n5v$bev$1@build.eclipse.org" type="cite">It is
requiered to create my own Negotiators together with a
NegotiatorFactory and introduce them via a extension point? </blockquote>
No, on the client-side you need to provide a credentials provider (see
SessionTest.java, too): 
 
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">



<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code> public CDOSession openSession(String repositoryName) 
 { 
 CDOSessionConfiguration configuration = createSessionConf iguration (repositoryName); 
 configuration.getAuthenticator().setCredentialsProvider(getTestCredentialsProvider()); 
 
 CDOSession session = configuration.openSession (); 
 configureSession(session); 
 session.addListener(sessionListener); 
 
 synchronized (sessions) 
 { 
 sessions.add(session); 
 } 
 
 return session; 
 }</code>
</td>
 </tr>
</tbody>
</table>
</div>

 
Does this help? 
 
Cheers 
/Eike 
 
---- 
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a> 
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a> 
 
 
<blockquote cite="mid:hg5n5v$bev$1@build.eclipse.org" type="cite">Sorry,
this is just a guess. Actually I don't have a idear to get started with
this. 
Of cause, if anybody else know how to do this, she or he can answer me
as well. This would be really nice.
 
 
Thanks a lot for your help.
 
Regards,
 
René
 
</blockquote>
</body>
</html>

--------------020202070909090109020607--

Re: CDO authentication [message #503946 is a reply to message #503559]

Wed, 16 December 2009 10:16

Eclipse User

Hi Eike,

I can't give you enough props for always answer me so quickly. This helps me a lot! Thank you for that.

Regarding the authentication problem, I downloaded the CDO test framework and had a closer look at the SessionTest class. I think I know how to introduce my own Usermanager and CredentialsProvider. Unfortunately I don't understand how to get this custom code combined with the cdo server. When I create a new plug-in project in eclipse, which depends on the org.eclipse.emf.cdo.server and the other necessary plug-ins, where should the declaration of my user manager appear? Or have I to choose another approach? At the end I want to deploy the cdo server with my user manager, to run it on another machine.

Regards,
René

Re: CDO authentication [message #503954 is a reply to message #503946]

Wed, 16 December 2009 10:27

Eclipse User

This is a multi-part message in MIME format.
--------------020204050008080407010002
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hi René,

The gastro examples show a programmatic way of starting a repository:

| *public static final class *Activator *extends *OSGiActivator
{
*public *Activator()
{
*super*(BUNDLE);
}

@Override
*protected **void *doStart() *throws *Exception
{
OM.LOG.info("Gastro server starting");
EmbeddedDataSource dataSource = *new *EmbeddedDataSource();
dataSource.setDatabaseName("/gastro");
dataSource.setCreateDatabase("create");

IMappingStrategy mappingStrategy = CDODBUtil.createHorizontalMappingStrategy(*true*);
IDBAdapter dbAdapter = *new *EmbeddedDerbyAdapter();
IDBConnectionProvider dbConnectionProvider = DBUtil.createConnectionProvider(dataSource);
IStore store = CDODBUtil.createStore(mappingStrategy, dbAdapter, dbConnectionProvider);

Map<String, String> props = *new *HashMap<String, String>();
props.put(IRepository.Props.OVERRIDE_UUID, "gastro");
props.put(IRepository.Props.SUPPORTING_AUDITS, "true");
props.put(IRepository.Props.VERIFYING_REVISIONS, "false");
props.put(IRepository.Props.CURRENT_LRU_CAPACITY, "100000");
props.put(IRepository.Props.REVISED_LRU_CAPACITY, "10000");

repository = CDOServerUtil.createRepository("gastro", store, props);
CDOServerUtil.addRepository(IPluginContainer.INSTANCE, repository);
CDOServerUtil.prepareContainer(IPluginContainer.INSTANCE);

acceptor = (IAcceptor)IPluginContainer.INSTANCE.getElement("org.eclipse.net4j.acceptors ", "tcp", "0.0.0.0:2036");
OM.LOG.info("Gastro server started");
}

@Override
*protected **void *doStop() *throws *Exception
{
OM.LOG.info("Gastro server stopping");
LifecycleUtil.deactivate(acceptor);
LifecycleUtil.deactivate(repository);
OM.LOG.info("Gastro server stopped");
}
}|

Does that help?

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

René schrieb:
> Hi Eike,
>
> I can't give you enough props for always answer me so quickly. This
> helps me a lot! Thank you for that.
>
> Regarding the authentication problem, I downloaded the CDO test
> framework and had a closer look at the SessionTest class. I think I
> know how to introduce my own Usermanager and CredentialsProvider.
> Unfortunately I don't understand how to get this custom code combined
> with the cdo server. When I create a new plug-in project in eclipse,
> which depends on the org.eclipse.emf.cdo.server and the other
> necessary plug-ins, where should the declaration of my user manager
> appear? Or have I to choose another approach? At the end I want to
> deploy the cdo server with my user manager, to run it on another machine.
>
> Regards,
> René
>

--------------020204050008080407010002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi René, 
 
The gastro examples show a programmatic way of starting a repository: 
 
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">



<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code> public static final class Activator extends OSGiActivator 
 { 
 public Activator() 
 { 
 super(BUNDLE); 
 } 
 
 @Override 
 protected void doStart() throws Exception 
 { 
 OM.LOG.info("Gastro server starting"); 
 EmbeddedDataSource dataSource = new EmbeddedDataSource(); 
 dataSource.setDatabaseName("/gastro"); 
 dataSource.setCreateDatabase("create"); 
 
 IMappingStrategy mappingStrategy = CDODBUtil.createHorizo ntalMappingStrategy (true); 
 IDBAdapter dbAdapter = new EmbeddedDerbyAdapter(); 
 IDBConnectionProvider dbConnectionProvider = DBUtil.creat eConnectionProvider (dataSource); 
 IStore store = CDODBUtil.createStore(mappingStrategy, dbAdapter, dbConnectionProvider ); 
 
 Map<String, String> props = new HashMap<String, String>(); 
 props.put(IRepository.Props.OVERRIDE_UUID, "gastro"); 
 props.put(IRepository.Props.SUPPORTING_AUDITS, "true"); 
 props.put(IRepository.Props.VERIFYING_REVISIONS, "false"); 
 props.put(IRepository.Props.CURRENT_LRU_CAPACITY, "100000"); 
 props.put(IRepository.Props.REVISED_LRU_CAPACITY, "10000"); 
 
 repository = CDOServerUtil.createRepository ("gastro", store, props); 
 CDOServerUtil.addRepository(IPluginContainer.INSTANCE, repository); 
 CDOServerUtil.prepareContainer(IPluginContainer.INSTANCE); 
 
 acceptor = (IAcceptor)IPluginContainer.INSTANCE.getElement("org.eclipse.net4j.acceptors", "tcp", "0.0.0.0:2036"); 
 OM.LOG.info("Gastro server started"); 
 } 
 
 @Override 
 protected void doStop() throws Exception 
 { 
 OM.LOG.info("Gastro server stopping"); 
 LifecycleUtil.deactivate(acceptor); 
 LifecycleUtil.deactivate(repository); 
 OM.LOG.info("Gastro server stopped"); 
 } 
 }</code>
</td>
 </tr>
</tbody>
</table>
</div>

 
Does that help? 
 
Cheers 
/Eike 
 
---- 
<a class="moz-txt-link-freetext" href="http://thegordian.blogspot.com">http://thegordian.blogspot.com</a> 
<a class="moz-txt-link-freetext" href="http://twitter.com/eikestepper">http://twitter.com/eikestepper</a> 
 
 
 
René schrieb:
<blockquote cite="mid:hgatjn$kh$1@build.eclipse.org" type="cite">Hi
Eike,
 
 
I can't give you enough props for always answer me so quickly. This
helps me a lot! Thank you for that.
 
 
Regarding the authentication problem, I downloaded the CDO test
framework and had a closer look at the SessionTest class. I think I
know how to introduce my own Usermanager and CredentialsProvider.
Unfortunately I don't understand how to get this custom code combined
with the cdo server. When I create a new plug-in project in eclipse,
which depends on the org.eclipse.emf.cdo.server and the other necessary
plug-ins, where should the declaration of my user manager appear? Or
have I to choose another approach? At the end I want to deploy the cdo
server with my user manager, to run it on another machine.
 
 
Regards,
 
René
 
 
</blockquote>
</body>
</html>

--------------020204050008080407010002--

Re: CDO authentication [message #505669 is a reply to message #503954]

Mon, 04 January 2010 05:46

Eclipse User

Hi Eike,

Hi Eike,

Please excuse my late response. My Christmas vacation starts on the day of your reply and I forgot to check the thread again. But thanks for your answer. I just downloaded the Gastro-Example and it seems to be very helpful!

Best Regards,
René

Re: CDO authentication [message #505972 is a reply to message #503954]

Tue, 05 January 2010 06:54

Eclipse User

Hi Eike,

I hope wouldn't be too annoying. The last two days I worked a little bit further on my project and tried to implement my own CDO-Repository authentification. Your tips were a huge help for that. Thanks again! But unfortunately I still got a little problem.
After setting up my own UserManager to repository (you described it above), I tried to set a ICredentialsProvider to the client-side session. But the Authentificator only accept an IPasswordCredentialsProvider. That didn't work out for me, because I have to realize the repository authentification with an already existing system, which is not username/password based. Can CDO 2.0 handle general authentification mechanism and if yes how can I do that?

Thanks a lot in advance.
Regards,
René

Re: CDO authentication [message #505986 is a reply to message #505972]

Tue, 05 January 2010 12:51

Eclipse User

Hi René,

Authentication and authorisation via CDO is a core requirement for ORMF also. I know that there is an enhancement request in Bugzilla for this. I am quite interested in cooperating with other parties that have this need to get something generally useful to the CDO community working. Would you be interested?

Cheers,
Joel

René wrote on Tue, 05 January 2010 11:54

Re: CDO authentication [message #506119 is a reply to message #505972]

Wed, 06 January 2010 04:32

Eclipse User

Hi René,

Maybe we should make the CDOSessionConfigurationImpl.setAuthenticator()
method public to enable applications to replace the authenticator
implementation. IIRC the CDO protocol (e.g.
org.eclipse.emf.internal.cdo.net4j.protocol.AuthenticationIn dication)
only calls the CDOAuthenticator.authenticate(byte[]) method.
Unfortunately I can not change any API for 2.0.x so you're left to
calling setAuthenticator on the internal Impl class for now. But if you
want to have that method publicly available you should file an
enhancement request.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

René schrieb:
> Hi Eike,
>
> I hope wouldn't be too annoying. The last two days I worked a little
> bit further on my project and tried to implement my own CDO-Repository
> authentification. Your tips were a huge help for that. Thanks again!
> But unfortunately I still got a little problem.
> After setting up my own UserManager to repository (you described it
> above), I tried to set a ICredentialsProvider to the client-side
> session. But the Authentificator only accept an
> IPasswordCredentialsProvider. That didn't work out for me, because I
> have to realize the repository authentification with an already
> existing system, which is not username/password based. Can CDO 2.0
> handle general authentification mechanism and if yes how can I do that?
>
> Thanks a lot in advance.
> Regards,
> René
>

Re: CDO authentication [message #506121 is a reply to message #505986]

Wed, 06 January 2010 04:35

Eclipse User

H i Guys,

There are some bugzillas:

259070: Provide secure storage based ICredentialsProvider
https://bugs.eclipse.org/bugs/show_bug.cgi?id=259070

262064: add support for user authentication and access control
https://bugs.eclipse.org/bugs/show_bug.cgi?id=262064

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Joel Rosi-Schwartz schrieb:
> Hi René,
>
> Authentication and authorisation via CDO is a core requirement for
> http://www.eclipse.org/ormf/ also. I know that there is an enhancement
> request in Bugzilla for this. I am quite interested in cooperating
> with other parties that have this need to get something generally
> useful to the CDO community working. Would you be interested?
>
> Cheers,
> Joel
>
> René wrote on Tue, 05 January 2010 11:54
>> Hi Eike,
>>
>> I hope wouldn't be too annoying. The last two days I worked a little
>> bit further on my project and tried to implement my own
>> CDO-Repository authentification. Your tips were a huge help for that.
>> Thanks again! But unfortunately I still got a little problem.
>> After setting up my own UserManager to repository (you described it
>> above), I tried to set a ICredentialsProvider to the client-side
>> session. But the Authentificator only accept an
>> IPasswordCredentialsProvider. That didn't work out for me, because I
>> have to realize the repository authentification with an already
>> existing system, which is not username/password based. Can CDO 2.0
>> handle general authentification mechanism and if yes how can I do that?
>>
>> Thanks a lot in advance.
>> Regards,
>> René
>
>

Re: CDO authentication [message #506127 is a reply to message #505986]

Wed, 06 January 2010 04:57

Eclipse User

Hi Joel,
I'm interested, but not quite sure want you with "get something generally useful". Do you want to specify the needs of authentication and authorization or help during the development? Eike had mentioned some Bugzilla Entries (see above), that indicate that this is already under development. You may be able to describe your intension a little bit more?

Best regards,
René

[Updated on: Wed, 06 January 2010 04:59] by Moderator

Re: CDO authentication [message #506134 is a reply to message #506127]

Wed, 06 January 2010 05:01

Eclipse User

René schrieb:
> [...] Eike had mentioned some Bugzilla Entries (see above), that
> indicate that this is already under development.
Generally the pure existance of a feature request does not mean that I
or somebody else is actually working on that! :P

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: CDO authentication [message #506144 is a reply to message #481114]

Wed, 06 January 2010 05:50

Eclipse User

Eike/René,

Actually I was referring to Bug 277075 - Access Control system in CDO This seems to have got off to a good started then waned. For my part (for ORMF) Authorisation and Authentication at the Object granularity is more than likely to be sufficient, but I appreciate that others who are using CDO for more sensitive applications where data laws apply will have more stringent requirements. So when I say "general" I mean that the work should cover what the majority of the community requires, but with a sensitivity that something useful is more important than a grand scheme that never gets achieved Wink

So the first step is find out what is actually needed. I would also like to look at a design that is extensible so that possibly we can achieve the easy use cases early on and then extend (or allow extension) for the more demanding use cases down the line.

To answer your question René, I would be interested in both helping to specify and realise this feature.

Cheers,
Joel

Re: CDO authentication [message #506154 is a reply to message #506144]

Wed, 06 January 2010 01:24

Eclipse User

This is a multi-part message in MIME format.
--------------050801070908080405040305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Joel Rosi-Schwartz schrieb:
> Eike/René,
>
> Actually I was referring to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075
Oh, I was looking for that but my keywords didn't get it.

> This seems to have got off to a good started then waned. For my part
> (for ORMF) Authorisation and Authentication at the Object granularity
> is more than likely to be sufficient, but I appreciate that others who
> are using CDO for more sensitive applications where data laws apply
> will have more stringent requirements. So when I say "general" I mean
> that the work should cover what the majority of the community
> requires, but with a sensitivity that something useful is more
> important than a grand scheme that never gets achieved ;) So the first
> step is find out what is actually needed. I would also like to look at
> a design that is extensible so that possibly we can achieve the easy
> use cases early on and then extend (or allow extension) for the more
> demanding use cases down the line.
Please note, that the needed hooks are already present in IRepository:

| /**
* A marker interface to indicate valid arguments to {@link IRepository#addHandler(Handler)} and
* {@link IRepository#removeHandler(Handler)}.
*
* @see ReadAccessHandler
* @see WriteAccessHandler
* @author Eike Stepper
* @since 2.0
*/
*public interface *Handler
{
}

/**
* Provides a way to handle revisions that are to be sent to the client.
*
* @author Eike Stepper
* @since 2.0
*/
*public interface *ReadAccessHandler *extends *Handler
{
/**
* Provides a way to handle revisions that are to be sent to the client.
*
* @param session
* The session that is going to send the revisions.
* @param revisions
* The revisions that are requested by the client. If the client must not see any of these revisions an
* unchecked exception must be thrown.
* @param additionalRevisions
* The additional revisions that are to be sent to the client because internal optimizers believe that they
* will be needed soon. If the client must not see any of these revisions they should be removed from the
* list.
* @throws RuntimeException
* to indicate that none of the revisions must be sent to the client. This exception will be visible at
* the client side!
*/
*public **void *handleRevisionsBeforeSending(ISession session, CDORevision[] revisions,
List<CDORevision> additionalRevisions) *throws *RuntimeException;
}

/**
* @author Eike Stepper
* @since 2.0
*/
*public interface *WriteAccessHandler *extends *Handler
{
/**
* Provides a way to handle transactions that are to be committed to the backend store.
*
* @param transaction
* The transaction that is going to be committed.
* @param commitContext
* The context of the commit operation that is to be executed against the backend store. The context can be
* used to introspect all aspects of the current commit operation.
* @param monitor
* A monitor that should be used by the implementor to avoid timeouts.
* @throws RuntimeException
* to indicate that the commit operation must not be executed against the backend store. This exception
* will be visible at the client side!
*/
*public **void *handleTransactionBeforeCommitting(ITransaction transaction, IStoreAccessor.CommitContext commitContext,
OMMonitor monitor) *throws *RuntimeException;
}|

Concrete handler implementations are not required to be part of the CDO
core.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> To answer your question René, I would be interested in both helping to
> specify and realise this feature.
>
> Cheers,
> Joel

--------------050801070908080405040305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Joel Rosi-Schwartz schrieb:
<blockquote cite="mid:hi1pt4$s20$1@build.eclipse.org" type="cite">Eike/René,
 
 
Actually I was referring to
<a class="moz-txt-link-freetext" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075">https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075</a> </blockquote>
Oh, I was looking for that but my keywords didn't get it. 
 
<blockquote cite="mid:hi1pt4$s20$1@build.eclipse.org" type="cite">This
seems to have got off to a good started then waned. For my part (for
ORMF) Authorisation and Authentication at the Object granularity is
more than likely to be sufficient, but I appreciate that others who are
using CDO for more sensitive applications where data laws apply will
have more stringent requirements. So when I say "general" I mean that
the work should cover what the majority of the community requires, but
with a sensitivity that something useful is more important than a grand
scheme that never gets achieved ;) So the first step is find out what
is actually needed. I would also like to look at a design that is
extensible so that possibly we can achieve the easy use cases early on
and then extend (or allow extension) for the more demanding use cases
down the line.
 
</blockquote>
Please note, that the needed hooks are already present in IRepository: 
 
<title></title>
<style type="text/css">

</style>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">



<div class="java" align="left">
<table bgcolor="#ffffff" border="0" cellpadding="3" cellspacing="0">
<tbody>
<tr>
 <td align="left" nowrap="nowrap"
valign="top"> <code> /** 
 * A marker interface to indicate valid arguments to

Re: CDO authentication [message #506161 is a reply to message #506119]

Wed, 06 January 2010 07:09

Eclipse User

Hi Eike,

thanks for your quick reply. It gave me the needed hint, where I have to look further.

The setAuthenticator()-method of the CDOSessionConfigurationImpl is already public. Only the interface CDOSessionConfiguration do not provide such a method. I think you meant this the absence of the public method. A hack to replace the authenticator implementation is so very easy. Cast the existing configuration to CDOSessionConfigurationImpl

((CDOSessionImpl)configuration).setAuthenticator(authenticator)

(note: you will get a Discouraged access warning)

I had a slightly deeper look into the authentication procedure and found out that a change of the SessionManager (it is on server side) is also required. The authenticator (it is on client side) only crypt the user password, given from an IPasswordCredentialsProvider and create a AuthentificationResult with the user name and the (crypted) password. The SessionManager evaluate the result and expects equality between the (crypted) password from the result and the (crypted) password from the user manager. Unfortunately that's not practicable for me. I have to query the existing authentication system and check if the user(id) is already authenticated. But again I think a little dirty hack help me out. I going to override the protected String authenticateUser(CDOServerProtocol protocol) method from the SessionManger in my own class and change the implementation. I hope I'm not completely wrong with that and it is not too dirty. Rolling Eyes

I'm not quite sure if it is required to make setAuthenticator()-method public. It depends on the decision how flexible the authentication mechanism should work in the future and maybe there is a better way to get flexibility. I will think a little bit more about that and create a enhancement request if i really need it.

Regards,
René

Re: CDO authentication [message #506163 is a reply to message #506161]

Wed, 06 January 2010 07:17

Eclipse User

René schrieb:
> Hi Eike,
>
> thanks for your quick reply. It gave me the needed hint, where I have
> to look further.
>
> The setAuthenticator()-method of the CDOSessionConfigurationImpl is
> already public. Only the interface CDOSessionConfiguration do not
> provide such a method. I think you meant this the absence of the
> public method. A hack to replace the authenticator implementation is
> so very easy. Cast the existing configuration to
> CDOSessionConfigurationImpl
> ((CDOSessionImpl)configuration).setAuthenticator(authenticat or)
That's what I meant ;-)

> (note: you will get a Discouraged access warning)
Sure.

>
> I had a slightly deeper look into the authentication procedure and
> found out that a change of the SessionManager (it is on server side)
> is also required. The authenticator (it is on client side) only crypt
> the user password, given from an IPasswordCredentialsProvider and
> create a AuthentificationResult with the user name and the (crypted)
> password. The SessionManager evaluate the result and expects equality
> between the (crypted) password from the result and the (crypted)
> password from the user manager. Unfortunately that's not practicable
> for me. I have to query the existing authentication system and check
> if the user(id) is already authenticated. But again I think a little
> dirty hack help me out. I going to override the protected String
> authenticateUser(CDOServerProtocol protocol) method from the
> SessionManger in my own class and change the implementation. I hope
> I'm not completely wrong with that and it is not too dirty. :roll:
I'm very open to suggestions (and patches) to make authentication even
more flexible in CDO 3.0.

> I'm not quite sure if it is required to make setAuthenticator()-method
> public. It depends on the decision how flexible the authentication
> mechanism should work in the future and maybe there is a better way to
> get flexibility. I will think a little bit more about that and create
> a enhancement request if i really need it.
Thank you.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> Regards,
> René

Re: CDO authentication [message #506187 is a reply to message #506144]

Wed, 06 January 2010 08:52

Eclipse User

Hi Joel,
Sorry I was only able to have a short look at the discussion about Bug 277075. It covers more authorization purposes. But Eikes suggestion to hook the ACS via the handlers, make a lot of sense for me.

None the less I focused more on an authentication part. My core need there is to have a flexible implementation approach. The developer should easily exchange the authentication mechanism to adapt to existing systems (like in my case) or support other authentication techniques (with a certificate perhaps).

Is it a good idea to open a new bug to cover the authentication part? All bugs I had seen are crosscutting between authentication and authorization.

Regards,
René

Joel Rosi-Schwartz wrote on Wed, 06 January 2010 05:50

Re: CDO authentication [message #506194 is a reply to message #506187]

Wed, 06 January 2010 09:05

Eclipse User

I understand your need and it highlights what a broad swath Auth* covers. All the more need to have a lot of flexibility Wink

As far as a new enhancement request I like to have Eike's thoughts, but my opinion is that it all should be addressed part and parcel.

Cheers,
Joel

René wrote on Wed, 06 January 2010 13:52

Joel Rosi-Schwartz wrote on Wed, 06 January 2010 05:50

[Updated on: Wed, 06 January 2010 04:08] by Moderator

Re: CDO authentication [message #506239 is a reply to message #506187]

Wed, 06 January 2010 11:16

Eclipse User

René schrieb:
> Hi Joel,
> Sorry I was only able to have a short look at the discussion about Bug
> 277075. It covers more authorization purposes. But Eikes suggestion to
> hook the ACS via the handlers, make a lot of sense for me.
> None the less I focused more on an authentication part. My core need
> there is to have a flexible implementation approach. The developer
> should easily exchange the authentication mechanism to adapt to
> existing systems (like in my case) or support other authentication
> techniques (with a certificate perhaps).
>
> Is it a good idea to open a new bug to cover the authentication part?
> All bugs I had seen are crosscutting between authentication and
> authorization.
If there is a concrete need for you please feel free to submit a
bugzilla ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> Regards,
> René
>
>
>
> Joel Rosi-Schwartz wrote on Wed, 06 January 2010 05:50
>> Eike/René,
>>
>> Actually I was referring to Bug 277075 - Access Control system in
>> CDO This seems to have got off to a good started then waned. For my
>> part (for ORMF) Authorisation and Authentication at the Object
>> granularity is more than likely to be sufficient, but I appreciate
>> that others who are using CDO for more sensitive applications where
>> data laws apply will have more stringent requirements. So when I say
>> "general" I mean that the work should cover what the majority of the
>> community requires, but with a sensitivity that something useful is
>> more important than a grand scheme that never gets achieved ;) So the
>> first step is find out what is actually needed. I would also like to
>> look at a design that is extensible so that possibly we can achieve
>> the easy use cases early on and then extend (or allow extension) for
>> the more demanding use cases down the line.
>>
>> To answer your question René, I would be interested in both helping
>> to specify and realise this feature.
>>
>> Cheers,
>> Joel
>
>

Re: CDO authentication [message #506928 is a reply to message #506239]

Mon, 11 January 2010 06:38

Eclipse User

Hi Eike,

I have used the last serval days to think about a flexible way for authentication in CDO. My basic idea is to outsource the (password based) authentication algorithm from the SessionManager#authenticate method into a UserManager#authenticate method. The SessionManager use the UserManager as Strategy, so you can hide the concrete authentication implementation and get a flexible approach. As result of the UserManager#authenticate returns a userId or raises a SecurityException which can be handled by the SessionManager.
To get this working several changes on the client side are required. At the moment all involved classes expects instances of IPasswordCredentials of IPasswordCredentialsProvider. This has to be changed into the generic ICredentials and ICredentialsProvider. Also the Authenticator#authenticate implementation has to be exchange able via interface or abstract class. This requires a public set method of the Authenticator as well.

I have tried to draw an UML diagram to visualize my suggestion (see it here). I hope it helps to understand. But of cause I am not an expert of the CDO architecture. I created my suggestion just from my point of view.

At the end I m not sure if I should create the enhancement request with this suggestion or just creates the request.

Regards,
René

Re: CDO authentication [message #506932 is a reply to message #506928]

Mon, 11 January 2010 06:52

Eclipse User

Hi René,

I appreciate your efforts and I suggest that you attach a patch to a new
bugzilla.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper

René schrieb:
> Hi Eike,
>
> I have used the last serval days to think about a flexible way for
> authentication in CDO. My basic idea is to outsource the (password
> based) authentication algorithm from the SessionManager#authenticate
> method into a UserManager#authenticate method. The SessionManager use
> the UserManager as Strategy, so you can hide the concrete
> authentication implementation and get a flexible approach. As result
> of the UserManager#authenticate returns a userId or raises a
> SecurityException which can be handled by the SessionManager. To get
> this working several changes on the client side are required. At the
> moment all involved classes expects instances of IPasswordCredentials
> of IPasswordCredentialsProvider. This has to be changed into the
> generic ICredentials and ICredentialsProvider. Also the
> Authenticator#authenticate implementation has to be exchange able via
> interface or abstract class. This requires a public set method of the
> Authenticator as well.
>
> I have tried to draw an UML diagram to visualize my suggestion
> ( http://img193.imageshack.us/img193/7138/authenticationclassd iag.png).
> I hope it helps to understand. But of cause I am not an expert of the
> CDO architecture. I created my suggestion just from my point of view.
>
> At the end I m not sure if I should create the enhancement request
> with this suggestion or just creates the request.
> Regards,
> René
>

Re: CDO authentication [message #506952 is a reply to message #506932]

Mon, 11 January 2010 08:56

Eclipse User

Hi,

I created a new Bugzilla. Eike had already mentioned it, but for the rest of you is here the link: Bug 299275 - Flexible Approach for an Authentication Mechanism

Regards,
René

Previous Topic:	Validation not happening
Next Topic:	[CDO] 3.0 Standalone server

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 08 17:39:19 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter