Discussion: OFBiz Security Refactor

[Adrian Crum]

It looks like we finally have a decent implementation for authenticating
users using LDAP - https://issues.apache.org/jira/browse/OFBIZ-811. This
will allow OFBiz installations to share user names and passwords with
the network.

I would like to expand it further so that OFBiz user permissions can be
managed outside OFBiz - using LDAP directory management tools. It would
be very convenient in an LDAP (or Active Directory) environment to treat
OFBiz user permissions just like any other network resource.

There are other authentication technologies that could be used this way
also - like Single Sign On, Radius, and so forth.

In a previous discussion it was suggested we could put a "mini LDAP
server" within OFBiz to accomplish this. The concept is to have a
network's LDAP server forward requests to OFBiz. OFBiz would then serve
its data in LDAP form.

At first I thought that was a great idea, but now I'm not so sure. I
believe it would be better to consolidate authentication and permission
checking, and then make the whole thing "swap-able." An OFBiz
installation could then swap OFBiz's entity-based user authentication
and permission checking with some other technology - like LDAP, SSO, etc.

The problem with implementing something like this is the way user
authentication and user permissions checking are handled in the existing
code. The two are separate - handled by separate classes in separate
components. In addition, the CRUD services for permissions are in a
third component. Clearly, there needs to be some consolidation.

At the least, we need to have the org.ofbiz.security.Security interface
expanded to have an authentication method and methods for permissions
CRUD operations. Each authentication technology could then have its own
implementation of the interface. An OFBiz installation could be
configured to use any of the available technologies using the
security.context property in the security.properties file.

What do you think?

-Adrian

[Shi Yusen]

Authentation? Authoration?

I think authentation is ok.

BTW, as the topic is on securtiy, I would suggest to consider adding
some implements to offer the ability to control read/write of entity
fields.

Shi Yusen/Beijing Langhua Ltd.


在 2008-06-19四的 10:54 -0700，Adrian Crum写道：

> It looks like we finally have a decent implementation for authenticating
> users using LDAP - https://issues.apache.org/jira/browse/OFBIZ-811. This
> will allow OFBiz installations to share user names and passwords with
> the network.
>
> I would like to expand it further so that OFBiz user permissions can be
> managed outside OFBiz - using LDAP directory management tools. It would
> be very convenient in an LDAP (or Active Directory) environment to treat
> OFBiz user permissions just like any other network resource.
>
> There are other authentication technologies that could be used this way
> also - like Single Sign On, Radius, and so forth.
>
> In a previous discussion it was suggested we could put a "mini LDAP
> server" within OFBiz to accomplish this. The concept is to have a
> network's LDAP server forward requests to OFBiz. OFBiz would then serve
> its data in LDAP form.
>
> At first I thought that was a great idea, but now I'm not so sure. I
> believe it would be better to consolidate authentication and permission
> checking, and then make the whole thing "swap-able." An OFBiz
> installation could then swap OFBiz's entity-based user authentication
> and permission checking with some other technology - like LDAP, SSO, etc.
>
> The problem with implementing something like this is the way user
> authentication and user permissions checking are handled in the existing
> code. The two are separate - handled by separate classes in separate
> components. In addition, the CRUD services for permissions are in a
> third component. Clearly, there needs to be some consolidation.
>
> At the least, we need to have the org.ofbiz.security.Security interface
> expanded to have an authentication method and methods for permissions
> CRUD operations. Each authentication technology could then have its own
> implementation of the interface. An OFBiz installation could be
> configured to use any of the available technologies using the
> security.context property in the security.properties file.
>
> What do you think?
>
> -Adrian

[Adrian Crum]

Shi Yusen wrote:
> BTW, as the topic is on securtiy, I would suggest to consider adding
> some implements to offer the ability to control read/write of entity
> fields.

That is usually handled by the presentation layer or in the service engine.

-Adrian

[byersa]

Adrian,

This is good timing for me as I need to implement a security scheme in which
a user's ability to perform CRUD operations is dependent on their level
within an organization (ie. someone is a divisional supervisor so they can
only modify records within their division and its departments). Does this
functionality already exist? Something similar was done for content
management.

If this functionality were to be rolled into LDAP service, then I think the
LDAP would need to handle a person's party group role associations. It sort
of makes sense that if you want to manage a person's authentication outside
of OFBiz that you would want to manage their position/role assignments in
the same context since they are often related.

Going back to the integrated CRUD permission scheme, I am prepared to write
that if it is agreed that it is the right way to go. I would make the
assumption that permissions are always determined by where a person exists
in an organizational structure (but certain Security permissions would
override this contextual permission granting) - which is architected by
using the PartyRelationship entity and a person's role within that party
group (div, dept, etc.) I would like to see PartyRelationship used to
associate roles of a person with a party group because it can be time aware
and it can enforce some checks by use of the PartyRelationshipType.

In general, I am thinking that it would be something like a divisional
supervisor needing to approve Content published by a departmental worker.
The Content record would need to be tied to a department PartyGroup and the
divisional supervisor is able to edit or publish the content by virtue of
their hierarchical position and "ADMIN" role. In other cases, instead of a
Content entity, it may be the ContactMech for an employee or a purchase
order approval. In all these cases, the entity in question needs to be tied
to a PartyGroup structure and the permission to perform the operation would
be determined by the same method once it was.

In content permission granting there was the concept of "purpose". For
instance, a departmental supervisor may be able approve some content for
publication if its purpose was the weekly newsletter, but not if it were for
a corporate report.

-Al

[Bruno Busco]

All,
I would like to bring in this discussion the framework/applications relation
and dependence.
With this I mean that, since we are going to release the framework by
itself, I guess the party will not included in it. On the other hand the
security is implemented in the framework.
So I ask, is it possible to have a basic framework with user
authentications, permissions and roles to be used in non strictly ERP
applications?

Thank you,
-Bruno


2008/6/19 Al Byers <[hidden email]>:

> Adrian,
>
> This is good timing for me as I need to implement a security scheme in
> which
> a user's ability to perform CRUD operations is dependent on their level
> within an organization (ie. someone is a divisional supervisor so they can
> only modify records within their division and its departments). Does this
> functionality already exist? Something similar was done for content
> management.
>
> If this functionality were to be rolled into LDAP service, then I think the
> LDAP would need to handle a person's party group role associations. It sort
> of makes sense that if you want to manage a person's authentication outside
> of OFBiz that you would want to manage their position/role assignments in
> the same context since they are often related.
>
> Going back to the integrated CRUD permission scheme, I am prepared to write
> that if it is agreed that it is the right way to go. I would make the
> assumption that permissions are always determined by where a person exists
> in an organizational structure (but certain Security permissions would
> override this contextual permission granting) - which is architected by
> using the PartyRelationship entity and a person's role within that party
> group (div, dept, etc.) I would like to see PartyRelationship used to
> associate roles of a person with a party group because it can be time aware
> and it can enforce some checks by use of the PartyRelationshipType.
>
> In general, I am thinking that it would be something like a divisional
> supervisor needing to approve Content published by a departmental worker.
> The Content record would need to be tied to a department PartyGroup and the
> divisional supervisor is able to edit or publish the content by virtue of
> their hierarchical position and "ADMIN" role. In other cases, instead of a
> Content entity, it may be the ContactMech for an employee or a purchase
> order approval. In all these cases, the entity in question needs to be tied
> to a PartyGroup structure and the permission to perform the operation would
> be determined by the same method once it was.
>
> In content permission granting there was the concept of "purpose". For
> instance, a departmental supervisor may be able approve some content for
> publication if its purpose was the weekly newsletter, but not if it were
> for
> a corporate report.
>
> -Al
>

[Adrian Crum]

Al,

How each network OS organizes LDAP objects and implements access to
those objects varies. I can only tell you how it works in NDS - I
haven't worked with Active Directory. I'll describe how NDS does things
and how I see OFBiz fitting in.

All network resources are objects. These include shared folders, shared
printers, servers, users, etc. All objects can have trustees assigned to
the object. A trustee is just another object. So, I could make the Jane
Smith user object a trustee of the Accounting Printer object - which
would grant Jane Smith access to the printer.

Objects can be grouped. So, instead of making Jane Smith the trustee of
Accounting Printer, I can have a group object called Accounting, make
the group a trustee of Accounting Printer, and put the Jane Smith object
in that group.

The Accounting group could also be a trustee of network folders that
people in accounting use, and other accounting-related network resources.

So, let's say I have an OFBiz object that contains other objects - one
for each OFBiz application. I can make the Accounting group a trustee of
   the OFBiz Accounting object. Tah-dah! Jane Smith (and anyone else in
the Accounting group) has permission to use the OFBiz Accounting
application. The application is treated just like any other network
resource.

By the way, specific permissions are assigned in the trustee
relationship - supervisor, read, create, erase, modify, etc.

So, the OFBiz permissions and roles and such could be mapped fairly
easily into an NDS environment (using LDAP).

I'll leave it up to you to determine if it will work in your scenario.
Indeed, we will need a number of users to share their requirements so
that the implementation is as generic as possible.

-Adrian

Al Byers wrote:

> Adrian,
>
> This is good timing for me as I need to implement a security scheme in which
> a user's ability to perform CRUD operations is dependent on their level
> within an organization (ie. someone is a divisional supervisor so they can
> only modify records within their division and its departments). Does this
> functionality already exist? Something similar was done for content
> management.
>
> If this functionality were to be rolled into LDAP service, then I think the
> LDAP would need to handle a person's party group role associations. It sort
> of makes sense that if you want to manage a person's authentication outside
> of OFBiz that you would want to manage their position/role assignments in
> the same context since they are often related.
>
> Going back to the integrated CRUD permission scheme, I am prepared to write
> that if it is agreed that it is the right way to go. I would make the
> assumption that permissions are always determined by where a person exists
> in an organizational structure (but certain Security permissions would
> override this contextual permission granting) - which is architected by
> using the PartyRelationship entity and a person's role within that party
> group (div, dept, etc.) I would like to see PartyRelationship used to
> associate roles of a person with a party group because it can be time aware
> and it can enforce some checks by use of the PartyRelationshipType.
>
> In general, I am thinking that it would be something like a divisional
> supervisor needing to approve Content published by a departmental worker.
> The Content record would need to be tied to a department PartyGroup and the
> divisional supervisor is able to edit or publish the content by virtue of
> their hierarchical position and "ADMIN" role. In other cases, instead of a
> Content entity, it may be the ContactMech for an employee or a purchase
> order approval. In all these cases, the entity in question needs to be tied
> to a PartyGroup structure and the permission to perform the operation would
> be determined by the same method once it was.
>
> In content permission granting there was the concept of "purpose". For
> instance, a departmental supervisor may be able approve some content for
> publication if its purpose was the weekly newsletter, but not if it were for
> a corporate report.
>
> -Al
>

[byersa]

Adrian,

This really helps. I am starting to see what the api for the integrated
permission utility would be. "Trustee" relationship is the word for the
relationship between objects (in my case, content records) and party with
permissions. In the NDS scheme can trustee groups be hierarchically
arranged?

It seems like somethings like Content records would not be appropriate for
the LDAP to manage and others, like ContactMechs, might blur the line of
what is appropriate.

In regards to Bruno's comments, I have not been keeping up with the
"framework only" project. Is it going to exclude Party? It seems like
permission checking would not be needed in an app that did not use Party.

-Al

[Adrian Crum]

Yes, the whole directory is arranged as a tree - which is an LDAP thing,
not an NDS thing.

By the way, groups in NDS would be similar to Domains in Active Directory.

Also keep in mind that I'm not proposing that we change how the current
permissions checking behaves. I'm only proposing a means of managing the
existing permissions checking process outside of OFBiz.

Associating content permissions to a user based on the user's role
within an organization would be handled best by the content component.

Regarding Bruno's comment - keep in mind that OFBiz users are not
necessarily parties, and parties are not necessarily OFBiz users. A user
would need to authenticate to the OFBiz framework, a party would not.

-Adrian

Al Byers wrote:

> Adrian,
>
> This really helps. I am starting to see what the api for the integrated
> permission utility would be. "Trustee" relationship is the word for the
> relationship between objects (in my case, content records) and party with
> permissions. In the NDS scheme can trustee groups be hierarchically
> arranged?
>
> It seems like somethings like Content records would not be appropriate for
> the LDAP to manage and others, like ContactMechs, might blur the line of
> what is appropriate.
>
> In regards to Bruno's comments, I have not been keeping up with the
> "framework only" project. Is it going to exclude Party? It seems like
> permission checking would not be needed in an app that did not use Party.
>
> -Al
>

[David E Jones]

I've had this discussion probably nearly 100 times with different  
clients and different people, and been involved in over a dozen  
different LDAP and SSO implementation. Based on that and reading this  
a few things come to mind:

1. only put in LDAP what other applications can share, since that is  
the whole point: sharing data in standard structures (as much as such  
things exist...); putting as much as possible into LDAP only adds  
effort with no reward, and in fact can cause performance and other  
problems compared to having that data in a database

2. the flows and touch points for different means of authentication do  
differ, so no single authentication object or something could be used  
for everything; for example most SSO stuff either looks for an HTTP  
header (as with the one now in SVN) or looks for an encrypted  
parameter or a parameter that can be looked up by talking to another  
system to prove the identity of the prospective user; on the other  
hand the LDAP stuff involves the entry and verification of a username  
and password, it's just that the data is checked against the LDAP  
server instead of the database; even with an LDAP server or SSO it  
doesn't mean you can get rid of the UserLogin entity, as it relates to  
other various other entities, unless the user is only a user and there  
is no party/contact/role/relationship/etc information needed for them;  
as has been mentioned permissions for a user could also go into LDAP  
(in some cases... not all though) which means the user wouldn't  
necessarily need a UserLogin record for that, but other things... :
( ... hello redundancy and more flexibility but more maintenance (some  
of which can/should be automated of course); BTW, this is true for ALL  
apps that support LDAP authentication, not just OFBiz, and in fact if  
you look at what certain other apps do it is pretty lame :)

3. in general it is a best practice to implement things manually and  
separately, and THEN look for redundancies and clean up, refactor, and  
consolidate the code once more is known; this helps avoid many  
mistakes and missteps, which unfortunately often make their way into  
OFBiz, and possibly even this discussion

-David



On Jun 19, 2008, at 11:54 AM, Adrian Crum wrote:

> It looks like we finally have a decent implementation for  
> authenticating users using LDAP - https://issues.apache.org/jira/browse/OFBIZ-811 
> . This will allow OFBiz installations to share user names and  
> passwords with the network.
>
> I would like to expand it further so that OFBiz user permissions can  
> be managed outside OFBiz - using LDAP directory management tools. It  
> would be very convenient in an LDAP (or Active Directory)  
> environment to treat OFBiz user permissions just like any other  
> network resource.
>
> There are other authentication technologies that could be used this  
> way also - like Single Sign On, Radius, and so forth.
>
> In a previous discussion it was suggested we could put a "mini LDAP  
> server" within OFBiz to accomplish this. The concept is to have a  
> network's LDAP server forward requests to OFBiz. OFBiz would then  
> serve its data in LDAP form.
>
> At first I thought that was a great idea, but now I'm not so sure. I  
> believe it would be better to consolidate authentication and  
> permission checking, and then make the whole thing "swap-able." An  
> OFBiz installation could then swap OFBiz's entity-based user  
> authentication and permission checking with some other technology -  
> like LDAP, SSO, etc.
>
> The problem with implementing something like this is the way user  
> authentication and user permissions checking are handled in the  
> existing code. The two are separate - handled by separate classes in  
> separate components. In addition, the CRUD services for permissions  
> are in a third component. Clearly, there needs to be some  
> consolidation.
>
> At the least, we need to have the org.ofbiz.security.Security  
> interface expanded to have an authentication method and methods for  
> permissions CRUD operations. Each authentication technology could  
> then have its own implementation of the interface. An OFBiz  
> installation could be configured to use any of the available  
> technologies using the security.context property in the  
> security.properties file.
>
> What do you think?
>
> -Adrian

[Adrian Crum-2]

--- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
I've had this discussion probably nearly 100 times with different  
clients and different people, and been involved in over a dozen  
different LDAP and SSO implementation. Based on that and reading this  
a few things come to mind:

1. only put in LDAP what other applications can share, since that is  
the whole point: sharing data in standard structures (as much as such  
things exist...); putting as much as possible into LDAP only adds  
effort with no reward, and in fact can cause performance and other  
problems compared to having that data in a database

So, what about keeping OFBiz permissions in LDAP? Did you read my reply to Al? That's what I'm hoping to achieve - sharing OFBiz permissions with network management applications.

-Adrian



     

[Shi Yusen]

Adrian,

I guess you mean unified authentation and unified authoration. In
pratice, unified authoration is useless.

Shi Yusen/Beijing Langhua Ltd.


在 2008-06-19四的 19:53 -0700，Adrian Crum写道：

> --- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
> I've had this discussion probably nearly 100 times with different  
> clients and different people, and been involved in over a dozen  
> different LDAP and SSO implementation. Based on that and reading this  
> a few things come to mind:
>
> 1. only put in LDAP what other applications can share, since that is  
> the whole point: sharing data in standard structures (as much as such  
> things exist...); putting as much as possible into LDAP only adds  
> effort with no reward, and in fact can cause performance and other  
> problems compared to having that data in a database
>
> So, what about keeping OFBiz permissions in LDAP? Did you read my reply to Al? That's what I'm hoping to achieve - sharing OFBiz permissions with network management applications.
>
> -Adrian
>
>
>
>      

[David E Jones]

I'm not sure if this is what you mean Shi, but I think we're on the  
same page with the problem with this: different applications tend to  
have different permission sets, business processes that pass through  
the applications, different ways of organizing and interpreting  
permissions, and so on. You could configure groups of users in LDAP  
(along with the authentication info), but added permissions as well is  
not terribly useful.

Some applications certainly put their permissions in LDAP, and are  
made to be configured entirely through LDAP, which becomes a data  
store that is an alternative to a relational database. However, it  
doesn't mean that other applications will be able to share that  
permission data, it just won't mean anything in the other apps.

-David


On Jun 19, 2008, at 10:26 PM, Shi Yusen wrote:

> Adrian,
>
> I guess you mean unified authentation and unified authoration. In
> pratice, unified authoration is useless.
>
> Shi Yusen/Beijing Langhua Ltd.
>
>
> 在 2008-06-19四的 19:53 -0700，Adrian Crum写道：
>> --- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
>> I've had this discussion probably nearly 100 times with different
>> clients and different people, and been involved in over a dozen
>> different LDAP and SSO implementation. Based on that and reading this
>> a few things come to mind:
>>
>> 1. only put in LDAP what other applications can share, since that is
>> the whole point: sharing data in standard structures (as much as such
>> things exist...); putting as much as possible into LDAP only adds
>> effort with no reward, and in fact can cause performance and other
>> problems compared to having that data in a database
>>
>> So, what about keeping OFBiz permissions in LDAP? Did you read my  
>> reply to Al? That's what I'm hoping to achieve - sharing OFBiz  
>> permissions with network management applications.
>>
>> -Adrian
>>
>>
>>
>>
>

[Shi Yusen]

Thank you David! My English is not good enough to express what I'm
thinking precisely. :)

Yes, "different ways of organizing and interpreting permissions".

Shi Yusen/Beijing Langhua Ltd.



在 2008-06-19四的 22:30 -0600，David E Jones写道：

> I'm not sure if this is what you mean Shi, but I think we're on the  
> same page with the problem with this: different applications tend to  
> have different permission sets, business processes that pass through  
> the applications, different ways of organizing and interpreting  
> permissions, and so on. You could configure groups of users in LDAP  
> (along with the authentication info), but added permissions as well is  
> not terribly useful.
>
> Some applications certainly put their permissions in LDAP, and are  
> made to be configured entirely through LDAP, which becomes a data  
> store that is an alternative to a relational database. However, it  
> doesn't mean that other applications will be able to share that  
> permission data, it just won't mean anything in the other apps.
>
> -David
>
>
> On Jun 19, 2008, at 10:26 PM, Shi Yusen wrote:
>
> > Adrian,
> >
> > I guess you mean unified authentation and unified authoration. In
> > pratice, unified authoration is useless.
> >
> > Shi Yusen/Beijing Langhua Ltd.
> >
> >
> > 在 2008-06-19四的 19:53 -0700，Adrian Crum写道：
> >> --- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
> >> I've had this discussion probably nearly 100 times with different
> >> clients and different people, and been involved in over a dozen
> >> different LDAP and SSO implementation. Based on that and reading this
> >> a few things come to mind:
> >>
> >> 1. only put in LDAP what other applications can share, since that is
> >> the whole point: sharing data in standard structures (as much as such
> >> things exist...); putting as much as possible into LDAP only adds
> >> effort with no reward, and in fact can cause performance and other
> >> problems compared to having that data in a database
> >>
> >> So, what about keeping OFBiz permissions in LDAP? Did you read my  
> >> reply to Al? That's what I'm hoping to achieve - sharing OFBiz  
> >> permissions with network management applications.
> >>
> >> -Adrian
> >>
> >>
> >>
> >>
> >
>

[Adrian Crum]

I don't agree that attempting to control OFBiz user permissions through
a management application is useless. There are a number of programs here
where I work that integrate well with NDS and allow me to control them
through a single management console.

I can't imagine being in a large corporation and having to create user
logins and passwords multiple times for each user. That would be an
administration nightmare!

Anyways...

David - you mentioned integrating OFBiz with LDAP for clients, yet I
don't see any evidence of it in OFBiz. Is there a chance you could share
your insights with me? Do you think it would be worth checking into
including Apache DS in OFBiz? Like we do with Tomcat?

-Adrian


David E Jones wrote:

>
> I'm not sure if this is what you mean Shi, but I think we're on the same
> page with the problem with this: different applications tend to have
> different permission sets, business processes that pass through the
> applications, different ways of organizing and interpreting permissions,
> and so on. You could configure groups of users in LDAP (along with the
> authentication info), but added permissions as well is not terribly useful.
>
> Some applications certainly put their permissions in LDAP, and are made
> to be configured entirely through LDAP, which becomes a data store that
> is an alternative to a relational database. However, it doesn't mean
> that other applications will be able to share that permission data, it
> just won't mean anything in the other apps.
>
> -David
>
>
> On Jun 19, 2008, at 10:26 PM, Shi Yusen wrote:
>
>> Adrian,
>>
>> I guess you mean unified authentation and unified authoration. In
>> pratice, unified authoration is useless.
>>
>> Shi Yusen/Beijing Langhua Ltd.
>>
>>
>> 在 2008-06-19四的 19:53 -0700，Adrian Crum写道：
>>> --- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
>>> I've had this discussion probably nearly 100 times with different
>>> clients and different people, and been involved in over a dozen
>>> different LDAP and SSO implementation. Based on that and reading this
>>> a few things come to mind:
>>>
>>> 1. only put in LDAP what other applications can share, since that is
>>> the whole point: sharing data in standard structures (as much as such
>>> things exist...); putting as much as possible into LDAP only adds
>>> effort with no reward, and in fact can cause performance and other
>>> problems compared to having that data in a database
>>>
>>> So, what about keeping OFBiz permissions in LDAP? Did you read my
>>> reply to Al? That's what I'm hoping to achieve - sharing OFBiz
>>> permissions with network management applications.
>>>
>>> -Adrian
>>>
>>>
>>>
>>>
>>
>
>

[Shi Yusen]

Hi List,

OFBiz-OpenOCES component is to add an implement instance of certificate
logon (not use SSL certificate) and digital signature functions to
OFBiz.

OFBiz-OpenOCES is in LGPL licience. You can get the source code from
Langhua's svn:
http://www.langhua.cn/langhua/ofbiz-components/OFBiz-OpenOCES/
Username/password is anon/anon.

Or check the code in viewvc:
http://www.langhua.cn/viewvc/ofbiz-components/OFBiz-OpenOCES/

More information on OFBiz, please visit http://ofbiz.apache.org/.
More information on OpenOCES, please visit http://www.openoces.org/.
More information on Langhua, please visit http://www.langhua.cn/en/.

Here are the steps of how to OFBiz-OpenOCES component.

1. Deploy OFBiz-OpenOCES component
1.1 In Eclipse, use svn to create a project and download source code
from
http://www.langhua.cn/langhua/ofbiz-components/OFBiz-OpenOCES/
Username/password is anon/anon.

1.2 Edit build.xml, change the deploy directory in target "ofbiz.copy".

1.3 Run "ofbiz.copy".
The files of OFBiz-OpenOCES component will be deployed to
$OFBIZ_HOME/specialpurpose/openoces/.

1.4 Edit specialpurpose/component-load.xml, add
    <load-component
component-location="${ofbiz.home}/specialpurpose/openoces"/>


2. Configurations
2.1 OpenLogon Configurations
2.1.1 Edit */webapp/WEB-INF/web.xml,
add the following:
    <servlet>
        <servlet-name>OpenLogonVerifier</servlet-name>

<servlet-class>cn.langhua.ofbiz.openlogon.OFBizOpenLogonVerifier</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>OpenLogonVerifier</servlet-name>
        <url-pattern>/openlogon/verifier</url-pattern>
    </servlet-mapping>

    <servlet>
        <servlet-name>OpenLogonDisplay</servlet-name>

<servlet-class>cn.langhua.ofbiz.openlogon.OFBizOpenLogonDisplay</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>OpenLogonDisplay</servlet-name>
        <url-pattern>/openlogon/display</url-pattern>
    </servlet-mapping>

and add /openlogon to allowedPaths:
        <init-param>
            <param-name>allowedPaths</param-name>

<param-value>/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images:/includes/maincss.css:/openlogon</param-value>
        </init-param>


2.1.2 Edit */webapp/WEB-INF/controller.xml,
change
        <event type="java" path="org.ofbiz.webapp.control.LoginWorker"
invoke="checkLogin" />
to
        <event type="java"
path="cn.langhua.ofbiz.openlogon.OFBizOpenLogon" invoke="checkLogin" />

change
        <event type="java" path="org.ofbiz.webapp.control.LoginWorker"
invoke="login"/>
to
        <event type="java"
path="cn.langhua.ofbiz.openlogon.OFBizOpenLogon" invoke="login"/>

2.1.3 Modify framework/common/webcommon/login.ftl to the following:
<#assign logonApplet =
Static["cn.langhua.ofbiz.openlogon.OFBizOpenLogonApplet"].createAppletCode(request, response, "specialpurpose/openoces/config/openlogon.xml", "challenge=mychallenge")>

<div class="screenlet login-screenlet">
  <div class="screenlet-title-bar">
    <h3>${uiLabelMap.CommonRegistered}</h3>
  </div>
  <div class="screenlet-body">
      <table cellspacing="0">
        <tr>
          <td align="center">${logonApplet}</td>
        </tr>
      </table>
  </div>
</div>
 
2.1.4 Config specialpurpose/openoces/config/openlogon.xml if you want a
different style.

2.1.5 Run "build" of OFBiz build.xml.


2.2 OpenSign Configurations
2.2.1 Edit */webapp/WEB-INF/web.xml,
add the following:
    <servlet>
        <servlet-name>OpenSignVerifier</servlet-name>

<servlet-class>cn.langhua.ofbiz.opensign.OFBizOpenSignVerifier</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>OpenSignVerifier</servlet-name>
        <url-pattern>/opensign/verifier</url-pattern>
    </servlet-mapping>

    <servlet>
        <servlet-name>OpenSignDisplay</servlet-name>

<servlet-class>cn.langhua.ofbiz.opensign.OFBizOpenSignDisplay</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>OpenSignDisplay</servlet-name>
        <url-pattern>/opensign/display</url-pattern>
    </servlet-mapping>

and add /opensign to allowedPaths:
        <init-param>
            <param-name>allowedPaths</param-name>

<param-value>/control:/select:/index.html:/index.jsp:/default.html:/default.jsp:/images:/includes/maincss.css:/opensign</param-value>
        </init-param>

2.2.2 Config specialpurpose/openoces/config/opensign.xml if you want a
different style.

2.2.3 Run "build" of OFBiz build.xml.

3. Usage
3.1 OpenLogon
If you run OFBiz in your local system, in web browser, visit
https://localhost:8443/catalog/
you'll see a logon applet similar to
openlogon.png(http://www.langhua.cn/viewvc/ofbiz-components/OFBiz-OpenOCES/trunk/docs/openlogon.png?view=markup) shown.

Tips:
If you use Linux/Unix, you can put your certificate in ~/.oces/, then
your certificate will be displayed in the select box.
If you use MS Windows, your certificate in IE will be automatically
filled
in the select box.
If you want to use this component in a production system, please make
sure you have changed the implements of
parseSecurityGroupId(X509Certificate cert) and
partyIdParser(X509Certificate cert) in
cn.langhua.ofbiz.openlogon.OFBizOpenLogon.java

3.2 OpenSign
You have to make some further customizations to store the digital
signatures.

4. Feedback
If you find any bugs or you have any suggestion on this component,
please send a email to [hidden email].

5. Thanks
Thanks Commercial Cryptogram Research Center of China who sponsored this
component.


Have a nice weekend,

Shi Yusen/Beijing Langhua Ltd.

[David E Jones]

On Jun 20, 2008, at 8:30 AM, Adrian Crum wrote:

> I don't agree that attempting to control OFBiz user permissions  
> through a management application is useless. There are a number of  
> programs here where I work that integrate well with NDS and allow me  
> to control them through a single management console.
>
> I can't imagine being in a large corporation and having to create  
> user logins and passwords multiple times for each user. That would  
> be an administration nightmare!

Integration with LDAP for usernames and passwords is a great idea, and  
perhaps even groups of users as I mentioned below.

What doesn't make as much sense is handling permissions through  
LDAP... that's where I think it is more effort than it is worth and  
doesn't make sense in most organizations... and I've never seen that  
done.


> Anyways...
>
> David - you mentioned integrating OFBiz with LDAP for clients, yet I  
> don't see any evidence of it in OFBiz. Is there a chance you could  
> share your insights with me? Do you think it would be worth checking  
> into including Apache DS in OFBiz? Like we do with Tomcat?

I'm not sure of what insights your interested in, but I'm happy to  
pontificate any time! ;)

As for integrating Apache DS in OFBiz, I don't know how useful it  
would be. If someone is just using OFBiz then it doesn't make sense  
and makes things harder instead of easier. If someone is deploying  
OFBiz in a corporate environment and they want to use LDAP, then they  
should already have an LDAP server around (Novell, Sun, Microsoft,  
OpenLDAP, Apache DS, or whatever), otherwise again it doesn't make  
much sense to use.

Still, I'd love to hear what others think about this, and if it does  
make sense and/or is desired, then we might as well go for it!

-David

> David E Jones wrote:
>> I'm not sure if this is what you mean Shi, but I think we're on the  
>> same page with the problem with this: different applications tend  
>> to have different permission sets, business processes that pass  
>> through the applications, different ways of organizing and  
>> interpreting permissions, and so on. You could configure groups of  
>> users in LDAP (along with the authentication info), but added  
>> permissions as well is not terribly useful.
>> Some applications certainly put their permissions in LDAP, and are  
>> made to be configured entirely through LDAP, which becomes a data  
>> store that is an alternative to a relational database. However, it  
>> doesn't mean that other applications will be able to share that  
>> permission data, it just won't mean anything in the other apps.
>> -David
>> On Jun 19, 2008, at 10:26 PM, Shi Yusen wrote:
>>> Adrian,
>>>
>>> I guess you mean unified authentation and unified authoration. In
>>> pratice, unified authoration is useless.
>>>
>>> Shi Yusen/Beijing Langhua Ltd.
>>>
>>>
>>> 在 2008-06-19四的 19:53 -0700，Adrian Crum写道：
>>>> --- On Thu, 6/19/08, David E Jones <[hidden email]> wrote:
>>>> I've had this discussion probably nearly 100 times with different
>>>> clients and different people, and been involved in over a dozen
>>>> different LDAP and SSO implementation. Based on that and reading  
>>>> this
>>>> a few things come to mind:
>>>>
>>>> 1. only put in LDAP what other applications can share, since that  
>>>> is
>>>> the whole point: sharing data in standard structures (as much as  
>>>> such
>>>> things exist...); putting as much as possible into LDAP only adds
>>>> effort with no reward, and in fact can cause performance and other
>>>> problems compared to having that data in a database
>>>>
>>>> So, what about keeping OFBiz permissions in LDAP? Did you read my  
>>>> reply to Al? That's what I'm hoping to achieve - sharing OFBiz  
>>>> permissions with network management applications.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>>
>>>>
>>>

[Adrian Crum-2]

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: OFBiz Security Refactor
> To: [hidden email]
> Date: Friday, June 20, 2008, 2:42 PM
> On Jun 20, 2008, at 8:30 AM, Adrian Crum wrote:
>
> > I don't agree that attempting to control OFBiz
> user permissions  
> > through a management application is useless. There are
> a number of  
> > programs here where I work that integrate well with
> NDS and allow me  
> > to control them through a single management console.
> >
> > I can't imagine being in a large corporation and
> having to create  
> > user logins and passwords multiple times for each
> user. That would  
> > be an administration nightmare!
>
> Integration with LDAP for usernames and passwords is a
> great idea, and  
> perhaps even groups of users as I mentioned below.
>
> What doesn't make as much sense is handling permissions
> through  
> LDAP... that's where I think it is more effort than it
> is worth and  
> doesn't make sense in most organizations... and
> I've never seen that  
> done.

I've seen it at work. We have Canon copiers, tape backup software, and our database software all integrated with Novell's eDirectory (their version of LDAP).

> > Anyways...
> >
> > David - you mentioned integrating OFBiz with LDAP for
> clients, yet I  
> > don't see any evidence of it in OFBiz. Is there a
> chance you could  
> > share your insights with me? Do you think it would be
> worth checking  
> > into including Apache DS in OFBiz? Like we do with
> Tomcat?
>
> I'm not sure of what insights your interested in, but
> I'm happy to  
> pontificate any time! ;)
>
> As for integrating Apache DS in OFBiz, I don't know how
> useful it  
> would be. If someone is just using OFBiz then it
> doesn't make sense  
> and makes things harder instead of easier. If someone is
> deploying  
> OFBiz in a corporate environment and they want to use LDAP,
> then they  
> should already have an LDAP server around (Novell, Sun,
> Microsoft,  
> OpenLDAP, Apache DS, or whatever), otherwise again it
> doesn't make  
> much sense to use.
>
> Still, I'd love to hear what others think about this,
> and if it does  
> make sense and/or is desired, then we might as well go for
> it!

I like the Apache Directory group's take on things: Why write user authentication code for your J2EE application, when you can just plug in an existing library? I guess I'm in their frame of mind - stuff like permissions should be kept in a directory, and the directory should be managed by an open source library.

Maybe this idea is too advanced for now - we can come back to it later.

I'm glad we finally have LDAP authentication. It makes my job much easier! I'll put the LDAP permissions thing on the shelf.

-Adrian




     

[Tim Ruppert]

+1 on the LDAP authentication Adrian - BIG WIN all the way around.  As  
for permission - I've been a part of this many times - everyone wants  
to do what you're describing when the idea first hits the group - then  
they test and start looking at their enterprise and let the actual  
applications handle authorization.  Just my two cents.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jun 20, 2008, at 7:39 PM, Adrian Crum wrote:

>> From: David E Jones <[hidden email]>
>> Subject: Re: Discussion: OFBiz Security Refactor
>> To: [hidden email]
>> Date: Friday, June 20, 2008, 2:42 PM
>> On Jun 20, 2008, at 8:30 AM, Adrian Crum wrote:
>>
>>> I don't agree that attempting to control OFBiz
>> user permissions
>>> through a management application is useless. There are
>> a number of
>>> programs here where I work that integrate well with
>> NDS and allow me
>>> to control them through a single management console.
>>>
>>> I can't imagine being in a large corporation and
>> having to create
>>> user logins and passwords multiple times for each
>> user. That would
>>> be an administration nightmare!
>>
>> Integration with LDAP for usernames and passwords is a
>> great idea, and
>> perhaps even groups of users as I mentioned below.
>>
>> What doesn't make as much sense is handling permissions
>> through
>> LDAP... that's where I think it is more effort than it
>> is worth and
>> doesn't make sense in most organizations... and
>> I've never seen that
>> done.
>
> I've seen it at work. We have Canon copiers, tape backup software,  
> and our database software all integrated with Novell's eDirectory  
> (their version of LDAP).
>
>>> Anyways...
>>>
>>> David - you mentioned integrating OFBiz with LDAP for
>> clients, yet I
>>> don't see any evidence of it in OFBiz. Is there a
>> chance you could
>>> share your insights with me? Do you think it would be
>> worth checking
>>> into including Apache DS in OFBiz? Like we do with
>> Tomcat?
>>
>> I'm not sure of what insights your interested in, but
>> I'm happy to
>> pontificate any time! ;)
>>
>> As for integrating Apache DS in OFBiz, I don't know how
>> useful it
>> would be. If someone is just using OFBiz then it
>> doesn't make sense
>> and makes things harder instead of easier. If someone is
>> deploying
>> OFBiz in a corporate environment and they want to use LDAP,
>> then they
>> should already have an LDAP server around (Novell, Sun,
>> Microsoft,
>> OpenLDAP, Apache DS, or whatever), otherwise again it
>> doesn't make
>> much sense to use.
>>
>> Still, I'd love to hear what others think about this,
>> and if it does
>> make sense and/or is desired, then we might as well go for
>> it!
>
> I like the Apache Directory group's take on things: Why write user  
> authentication code for your J2EE application, when you can just  
> plug in an existing library? I guess I'm in their frame of mind -  
> stuff like permissions should be kept in a directory, and the  
> directory should be managed by an open source library.
>
> Maybe this idea is too advanced for now - we can come back to it  
> later.
>
> I'm glad we finally have LDAP authentication. It makes my job much  
> easier! I'll put the LDAP permissions thing on the shelf.
>
> -Adrian
>
>
>
>
>