LDAP Module Implementation Issue

[Mario Perez]

Hello everyone,

We are students from California State University, Long Beach. We are currently working on a module that will externalize user
management through an LDAP server.

As stated in Ticket #623, our first thought was to use AOP to "intercept" the current authentication.
That is not possible because authenticate() does not exist in UserService. Everything goes through the UserContext.authenticate()
and ContextDAO.authenticate(). Therefore, there is no point to add an advisor that will let the
module use an LDAP server to authenticate users.

Moreover, Ticket #1748 (Move business logic for authentication into
service layer) modify the current way the authentication is done. We know it's not a easy decision as major worries have to be
considered such as security and modification of the core code.

The only point I see to wrap a unique service method (such as
UserService.authenticate(username, password, contextDAO) is now between
Context.authenticate(username,password) and UserContext.authenticate(username, password, contextDAO).
Through AOP we could replace the ContextDAO implementation to one that connects to LDAP instead of the database.

In sum, we are inquiring about information on a potential solution to this problem. Has anyone worked
with this problem who can point us down the right path for solving the authentication issue?

You can see our profiles here:
http://openmrs.org/wiki/User:Apoulet
http://openmrs.org/wiki/User:Flexapec
http://openmrs.org/wiki/User:MiguelSpain
http://openmrs.org/wiki/User:Mperez"

[Ben Wolfe]

Hmm, that is an interesting quandary.  I think the best solution might
be to use AOP around the DAO.  Although we usually don't do aop around
those...  I'm not a huge fan of moving the HibernateUserContextDAO logic
to the UserService, but perhaps after the reworking of the business
logic (in that ticket you mentioned) it makes more sense.

Ben

Mario Perez wrote:

> Hello everyone,
>
> We are students from California State University, Long Beach. We are
> currently working on a module that will externalize user
> management through an LDAP server.
>
> As stated in Ticket #623, our first thought was to use AOP to "intercept"
> the current authentication.
> That is not possible because authenticate() does not exist in UserService.
> Everything goes through the UserContext.authenticate()
> and ContextDAO.authenticate(). Therefore, there is no point to add an
> advisor that will let the
> module use an LDAP server to authenticate users.
>
> Moreover, Ticket #1748 (Move business logic for authentication into
> service layer) modify the current way the authentication is done. We know
> it's not a easy decision as major worries have to be
> considered such as security and modification of the core code.
>
> The only point I see to wrap a unique service method (such as
> UserService.authenticate(username, password, contextDAO) is now between
> Context.authenticate(username,password) and
> UserContext.authenticate(username, password, contextDAO).
> Through AOP we could replace the ContextDAO implementation to one that
> connects to LDAP instead of the database.
>
> In sum, we are inquiring about information on a potential solution to this
> problem. Has anyone worked
> with this problem who can point us down the right path for solving the
> authentication issue?
>
> You can see our profiles here:
> http://openmrs.org/wiki/User:Apoulet
> http://openmrs.org/wiki/User:Flexapec
> http://openmrs.org/wiki/User:MiguelSpain
> http://openmrs.org/wiki/User:Mperez"
>  

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[Darius Jazayeri-3]

Authenticating against LDAP versus against local credentials is a Service-layer function, not a DAO-layer function, so I think it is appropriate for us to reorganize the code such that there is a Service-layer function to override.

Maybe we need to add a new service called AuthenticationService or something like that. In the same way that we distinguish between User and LoginCredential objects, we could split that functionality.

-Darius

On Sat, Nov 7, 2009 at 6:33 AM, Ben Wolfe <[hidden email]> wrote:

Hmm, that is an interesting quandary.  I think the best solution might be to use AOP around the DAO.  Although we usually don't do aop around those...  I'm not a huge fan of moving the HibernateUserContextDAO logic to the UserService, but perhaps after the reworking of the business logic (in that ticket you mentioned) it makes more sense.
Ben

Mario Perez wrote:

Hello everyone,
We are students from California State University, Long Beach. We are
currently working on a module that will externalize user
management through an LDAP server.

As stated in Ticket #623, our first thought was to use AOP to "intercept"
the current authentication.
That is not possible because authenticate() does not exist in UserService.
Everything goes through the UserContext.authenticate()
and ContextDAO.authenticate(). Therefore, there is no point to add an
advisor that will let the
module use an LDAP server to authenticate users.

Moreover, Ticket #1748 (Move business logic for authentication into
service layer) modify the current way the authentication is done. We know
it's not a easy decision as major worries have to be considered such as security and modification of the core code.

The only point I see to wrap a unique service method (such as
UserService.authenticate(username, password, contextDAO) is now between
Context.authenticate(username,password) and
UserContext.authenticate(username, password, contextDAO).
Through AOP we could replace the ContextDAO implementation to one that
connects to LDAP instead of the database.

In sum, we are inquiring about information on a potential solution to this
problem. Has anyone worked
with this problem who can point us down the right path for solving the
authentication issue?

You can see our profiles here:
http://openmrs.org/wiki/User:Apoulet
http://openmrs.org/wiki/User:Flexapec
http://openmrs.org/wiki/User:MiguelSpain
http://openmrs.org/wiki/User:Mperez"
 

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

---

[hidden email] from OpenMRS Developers' mailing list

[Ben Wolfe]

Some javascript/style in this post has been disabled (why?)

An AuthenticationService (or some other name) would be fine with me.  If we restrict its methods to what ContextDAO is doing, we could make it private to the ServiceContext so that people don't try to use it instead of going through Context.authenticate().

Ben

Darius Jazayeri wrote:

Authenticating against LDAP versus against local credentials is a Service-layer function, not a DAO-layer function, so I think it is appropriate for us to reorganize the code such that there is a Service-layer function to override.

Maybe we need to add a new service called AuthenticationService or something like that. In the same way that we distinguish between User and LoginCredential objects, we could split that functionality.

-Darius

On Sat, Nov 7, 2009 at 6:33 AM, Ben Wolfe <[hidden email]> wrote:

Hmm, that is an interesting quandary.  I think the best solution might be to use AOP around the DAO.  Although we usually don't do aop around those...  I'm not a huge fan of moving the HibernateUserContextDAO logic to the UserService, but perhaps after the reworking of the business logic (in that ticket you mentioned) it makes more sense.
Ben

Mario Perez wrote:

Hello everyone,
We are students from California State University, Long Beach. We are
currently working on a module that will externalize user
management through an LDAP server.

As stated in Ticket #623, our first thought was to use AOP to "intercept"
the current authentication.
That is not possible because authenticate() does not exist in UserService.
Everything goes through the UserContext.authenticate()
and ContextDAO.authenticate(). Therefore, there is no point to add an
advisor that will let the
module use an LDAP server to authenticate users.

Moreover, Ticket #1748 (Move business logic for authentication into
service layer) modify the current way the authentication is done. We know
it's not a easy decision as major worries have to be considered such as security and modification of the core code.

The only point I see to wrap a unique service method (such as
UserService.authenticate(username, password, contextDAO) is now between
Context.authenticate(username,password) and
UserContext.authenticate(username, password, contextDAO).
Through AOP we could replace the ContextDAO implementation to one that
connects to LDAP instead of the database.

In sum, we are inquiring about information on a potential solution to this
problem. Has anyone worked
with this problem who can point us down the right path for solving the
authentication issue?

You can see our profiles here:
http://openmrs.org/wiki/User:Apoulet
http://openmrs.org/wiki/User:Flexapec
http://openmrs.org/wiki/User:MiguelSpain
http://openmrs.org/wiki/User:Mperez"
 

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Burke Mamlin]

Some javascript/style in this post has been disabled (why?)

Authentication is not a service; rather, it's a feature (requirement) of using an OpenMRS Context (so, I'm not a fan of AuthenticationService).  OpenMRS-specific authentication steps -- e.g., forgiving a hyphen in a login name -- should be moved into the service (#1748) precisely to allow OpenMRS-specific business to apply across all authentication schemes (whether via Hibernate, LDAP, or future alternatives).

How about an AuthenticationScheme interface to replace ContextDAO for the authenticate method -- e.g., loading a DatabaseAuthenticationScheme implementation by default and paving the way for an LDAPAuthenticationScheme to be substituted via applicationContext.xml?  AuthenticationScheme interface would have a single method of authenticate(String username, String password). 

Cheers,

-Burke

On Nov 12, 2009, at 1:09 AM, Ben Wolfe wrote:

An AuthenticationService (or some other name) would be fine with me.  If we restrict its methods to what ContextDAO is doing, we could make it private to the ServiceContext so that people don't try to use it instead of going through Context.authenticate().

Ben

Darius Jazayeri wrote:

Authenticating against LDAP versus against local credentials is a Service-layer function, not a DAO-layer function, so I think it is appropriate for us to reorganize the code such that there is a Service-layer function to override.

Maybe we need to add a new service called AuthenticationService or something like that. In the same way that we distinguish between User and LoginCredential objects, we could split that functionality.

-Darius

On Sat, Nov 7, 2009 at 6:33 AM, Ben Wolfe <[hidden email]> wrote:

Hmm, that is an interesting quandary.  I think the best solution might be to use AOP around the DAO.  Although we usually don't do aop around those...  I'm not a huge fan of moving the HibernateUserContextDAO logic to the UserService, but perhaps after the reworking of the business logic (in that ticket you mentioned) it makes more sense.
Ben

Mario Perez wrote:

Hello everyone,
We are students from California State University, Long Beach. We are
currently working on a module that will externalize user
management through an LDAP server.

As stated in Ticket #623, our first thought was to use AOP to "intercept"
the current authentication.
That is not possible because authenticate() does not exist in UserService.
Everything goes through the UserContext.authenticate()
and ContextDAO.authenticate(). Therefore, there is no point to add an
advisor that will let the
module use an LDAP server to authenticate users.

Moreover, Ticket #1748 (Move business logic for authentication into
service layer) modify the current way the authentication is done. We know
it's not a easy decision as major worries have to be considered such as security and modification of the core code.

The only point I see to wrap a unique service method (such as
UserService.authenticate(username, password, contextDAO) is now between
Context.authenticate(username,password) and
UserContext.authenticate(username, password, contextDAO).
Through AOP we could replace the ContextDAO implementation to one that
connects to LDAP instead of the database.

In sum, we are inquiring about information on a potential solution to this
problem. Has anyone worked
with this problem who can point us down the right path for solving the
authentication issue?

You can see our profiles here:
http://openmrs.org/wiki/User:Apoulet
http://openmrs.org/wiki/User:Flexapec
http://openmrs.org/wiki/User:MiguelSpain
http://openmrs.org/wiki/User:Mperez"
 

---

[hidden email] from OpenMRS Developers' mailing list

[Darius Jazayeri-2]

The quickest to implement would be to put the authenticate method in a service (or something that AOP can advise) as previously discussed, but Burke you are right that this is a fundamental enough operation that we should do it "right" instead of with general-purpose AOP.

Should you be able to have multiple active authentication schemes at a time (eg try DB first, and LDAP if that fails)? I think yes.

I assume other schemes are not required to work exactly like the openmrs one (LDAP doesn't have a system id, presumably), so I like the idea of having the scheme just implement authenticate (string, string).

-Darius (via his phone)

On Nov 15, 2009 11:49 AM, "Burke Mamlin" <[hidden email]> wrote:

Authentication is not a service; rather, it's a feature (requirement) of using an OpenMRS Context (so, I'm not a fan of AuthenticationService).  OpenMRS-specific authentication steps -- e.g., forgiving a hyphen in a login name -- should be moved into the service (#1748) precisely to allow OpenMRS-specific business to apply across all authentication schemes (whether via Hibernate, LDAP, or future alternatives).

How about an AuthenticationScheme interface to replace ContextDAO for the authenticate method -- e.g., loading a DatabaseAuthenticationScheme implementation by default and paving the way for an LDAPAuthenticationScheme to be substituted via applicationContext.xml?  AuthenticationScheme interface would have a single method of authenticate(String username, String password). 

Cheers,

-Burke

On Nov 12, 2009, at 1:09 AM, Ben Wolfe wrote: > > An AuthenticationService (or some other name) w...

---

Click here to unsubscribe from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Burke Mamlin]

Some javascript/style in this post has been disabled (why?)

Or perhaps it should be authenticate(LoginCredentials) instead of (String, String) to allow for more future flexibility. :-)

If you want to support DB-then-LDAP, it would be a third scheme (DbThenLdapAuthenticationScheme) that implements the business of which to try first, when to fall back, etc.

Cheers, 

-Burke

On Nov 15, 2009, at 1:24 PM, Darius Jazayeri <[hidden email]> wrote:

The quickest to implement would be to put the authenticate method in a service (or something that AOP can advise) as previously discussed, but Burke you are right that this is a fundamental enough operation that we should do it "right" instead of with general-purpose AOP.

Should you be able to have multiple active authentication schemes at a time (eg try DB first, and LDAP if that fails)? I think yes.

I assume other schemes are not required to work exactly like the openmrs one (LDAP doesn't have a system id, presumably), so I like the idea of having the scheme just implement authenticate (string, string).

-Darius (via his phone)

On Nov 15, 2009 11:49 AM, "Burke Mamlin" <[hidden email]> wrote:

Authentication is not a service; rather, it's a feature (requirement) of using an OpenMRS Context (so, I'm not a fan of AuthenticationService).  OpenMRS-specific authentication steps -- e.g., forgiving a hyphen in a login name -- should be moved into the service (#1748) precisely to allow OpenMRS-specific business to apply across all authentication schemes (whether via Hibernate, LDAP, or future alternatives).

How about an AuthenticationScheme interface to replace ContextDAO for the authenticate method -- e.g., loading a DatabaseAuthenticationScheme implementation by default and paving the way for an LDAPAuthenticationScheme to be substituted via applicationContext.xml?  AuthenticationScheme interface would have a single method of authenticate(String username, String password). 

Cheers,

-Burke

On Nov 12, 2009, at 1:09 AM, Ben Wolfe wrote: > > An AuthenticationService (or some other name) w...

---

Click here to unsubscribe from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Darius Jazayeri-2]

Or else you allow modules to provide authenticqation schemes and you have the administrator indicate which are enabled and in what order.

(Fun fact: burke is sitting 4 seats to my right and we're listening to andy k talk at AMIA.)

-Darius (via his phone)

On Nov 15, 2009 4:02 PM, "Burke Mamlin" <[hidden email]> wrote:

Or perhaps it should be authenticate(LoginCredentials) instead of (String, String) to allow for more future flexibility. :-)

If you want to support DB-then-LDAP, it would be a third scheme (DbThenLdapAuthenticationScheme) that implements the business of which to try first, when to fall back, etc.

Cheers, 

-Burke

On Nov 15, 2009, at 1:24 PM, Darius Jazayeri <[hidden email]> wrote: > The quickest to imple...

________________________________ Click here to unsubscribe from OpenMRS Developers' mailing list

---

[hidden email] from OpenMRS Developers' mailing list

[Mario Perez]

Hello,

Thanks all for responding on the issue.
Unfortunately, for our class we need to have an implementation working, as for now we have a quick and dirty AuthenticateService.
I guess we could continue to work on this path to have something proper while keeping in mind that later-on authentication would be provided as scheme as Burke proposed.
I am just wondering if the schema providing solution fits in the scope of a module's abilities ... ( How can it change the applicationContext.xml ?)

Thank you in advance,
Mario and team members

Darius Jazayeri-2 wrote:

Or else you allow modules to provide authenticqation schemes and you have
the administrator indicate which are enabled and in what order.

(Fun fact: burke is sitting 4 seats to my right and we're listening to andy
k talk at AMIA.)

-Darius (via his phone)

On Nov 15, 2009 4:02 PM, "Burke Mamlin" <[e-mail]> wrote:

Or perhaps it should be authenticate(LoginCredentials) instead of (String,
String) to allow for more future flexibility. :-)

If you want to support DB-then-LDAP, it would be a third scheme
(DbThenLdapAuthenticationScheme) that implements the business of which to
try first, when to fall back, etc.

Cheers,

-Burke

On Nov 15, 2009, at 1:24 PM, Darius Jazayeri <[e-mail]> wrote: >
The quickest to imple...

________________________________ Click here to unsubscribe from OpenMRS
Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [e-mail] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[e-mail]?body=SIGNOFF%20openmrs-devel-l]

[Ben Wolfe]

Some javascript/style in this post has been disabled (why?)

Modules can add anything to the spring definition by putting something into their own moduleApplicationContext.xml file.  Adding an authentication scheme would probably happen similar to how an implementation for the serialization happens.  See the serialization.xstream module, SerializationServiceImpl, and http://dev.openmrs.org/browser/openmrs/trunk/metadata/api/spring/applicationContext-service.xml#L313

http://openmrs.org/wiki/Module_Application_Context_File

Ben

Mario Perez wrote:

Hello,

Thanks all for responding on the issue. 
Unfortunately, for our class we need to have an implementation working, as
for now we have a quick and dirty AuthenticateService.
I guess we could continue to work on this path to have something proper
while keeping in mind that later-on authentication would be provided as
scheme as Burke proposed.
I am just wondering if the schema providing solution fits in the scope of a
module's abilities ... ( How can it change the applicationContext.xml ?)

Thank you in advance,
Mario and team members


Darius Jazayeri-2 wrote:
  

Or else you allow modules to provide authenticqation schemes and you have
the administrator indicate which are enabled and in what order.

(Fun fact: burke is sitting 4 seats to my right and we're listening to
andy
k talk at AMIA.)

-Darius (via his phone)

On Nov 15, 2009 4:02 PM, "Burke Mamlin" [hidden email] wrote:

Or perhaps it should be authenticate(LoginCredentials) instead of (String,
String) to allow for more future flexibility. :-)

If you want to support DB-then-LDAP, it would be a third scheme
(DbThenLdapAuthenticationScheme) that implements the business of which to
try first, when to fall back, etc.

Cheers,

-Burke

On Nov 15, 2009, at 1:24 PM, Darius Jazayeri [hidden email] wrote:
    

The quickest to imple...

________________________________ Click here to unsubscribe from OpenMRS
Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[hidden email] with "SIGNOFF openmrs-devel-l" in the  body
(not the subject) of your e-mail.

[[hidden email]]


    

---

[hidden email] from OpenMRS Developers' mailing list