[OFBiz] Dev - RE: Dev Digest, Vol 12, Issue 33

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[OFBiz] Dev - RE: Dev Digest, Vol 12, Issue 33

Ashish Hareet
Si,

>...to change the permission structure of the core OFBiz
>applications and try to get those incorporated back into OFBiz.

As tempting as this idea sounded to me first(when I started tweaking with
the security stuff), it wouldn't be the right way to go. For me to push
a feature back into the core OfBiz framework, it needs to pass my own
scrutiny. The current OfBiz security implementation is just fine &
my custom mods are very specific to our client. So I don't see the need
to put my security implementation back into OfBiz.

Given my situation, I'm sure that the 2 chocies I'm left with are
1. Use system login's for services. There is support already built-in
2. Modify the services I'll be using to use my security principles

Si, have a look at LoginServices.userLogin, the code actually does
something special with system login's. Let me know what you think.

I'm looking for confirmation whether this would be a good way to
provide security to services which are not in the realm of the
logged in users security principles.

Thanks
Ashish Hareet




-------- Original Message --------
Ashish,

Again, just my personal opinion, but I think you've formulated your
problem in a way that permits only one answer.  If you must keep the
core as-is AND you need a different permission structure for their
users, then it seems that the way you've done it is the only solution.

I still think the better solution would have been to change the
permission structure of the core OFBiz applications and try to get those
incorporated back into OFBiz.  You could have avoided essentially
building two security frameworks--one that originally came with OFBiz,
one that you built on top of it which relies on pushing in arbitrary
user logins.

This is one advantage of working with open source--you don't have to
keep the core "as is" but can tailor it for your needs or improve upon it.
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - RE: Dev Digest, Vol 12, Issue 33

Si Chen-2
Ashish,

I'm sorry, this is where my knowledge of OFBiz fails me.  I'm not sure
why there is this special treatment for system logins.  It is set to
disabled from the seed data, so perhaps it is an older way of doing
things.  But it's better if David & Andy can weigh in on this.

As for your two options, just go with the ones which takes less time.  
You would know your specific needs best...

Si

Ashish Hareet wrote:

>Si,
>
>  
>
>>...to change the permission structure of the core OFBiz
>>applications and try to get those incorporated back into OFBiz.
>>    
>>
>
>As tempting as this idea sounded to me first(when I started tweaking with
>the security stuff), it wouldn't be the right way to go. For me to push
>a feature back into the core OfBiz framework, it needs to pass my own
>scrutiny. The current OfBiz security implementation is just fine &
>my custom mods are very specific to our client. So I don't see the need
>to put my security implementation back into OfBiz.
>
>Given my situation, I'm sure that the 2 chocies I'm left with are
>1. Use system login's for services. There is support already built-in
>2. Modify the services I'll be using to use my security principles
>
>Si, have a look at LoginServices.userLogin, the code actually does
>something special with system login's. Let me know what you think.
>
>I'm looking for confirmation whether this would be a good way to
>provide security to services which are not in the realm of the
>logged in users security principles.
>
>Thanks
>Ashish Hareet
>
>
>
>
>-------- Original Message --------
>Ashish,
>
>Again, just my personal opinion, but I think you've formulated your
>problem in a way that permits only one answer.  If you must keep the
>core as-is AND you need a different permission structure for their
>users, then it seems that the way you've done it is the only solution.
>
>I still think the better solution would have been to change the
>permission structure of the core OFBiz applications and try to get those
>incorporated back into OFBiz.  You could have avoided essentially
>building two security frameworks--one that originally came with OFBiz,
>one that you built on top of it which relies on pushing in arbitrary
>user logins.
>
>This is one advantage of working with open source--you don't have to
>keep the core "as is" but can tailor it for your needs or improve upon it.
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
>  
>
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [OFBiz] Dev - RE: Security Questions

David E. Jones

The system accounts are for special purpose maintenance services that  
run and such, and should not ever be used in things involving user  
interaction.

In fact, the permissions really should be changed or the user should  
be associated with permissions for the service the user needs to run.  
Not doing so means that the real user is not authenticated in the  
logic layer, and that is a really big security and auditability  
issue. In fact, it may even violate certain new standards, even  
though not all companies really have to abide by them yet. If you are  
constrained by something like the Sarbanes-Oxley, this is certainly  
out of the question. In fact, if you do credit card processing for  
Visa or MasterCard cards then unique user login credentials and  
traceability are a really big deal, and if audited could cause problems.

-David


On Aug 1, 2005, at 6:06 PM, Si Chen wrote:

> Ashish,
>
> I'm sorry, this is where my knowledge of OFBiz fails me.  I'm not  
> sure why there is this special treatment for system logins.  It is  
> set to disabled from the seed data, so perhaps it is an older way  
> of doing things.  But it's better if David & Andy can weigh in on  
> this.
>
> As for your two options, just go with the ones which takes less  
> time.  You would know your specific needs best...
>
> Si
>
> Ashish Hareet wrote:
>
>
>> Si,
>>
>>
>>
>>> ...to change the permission structure of the core OFBiz  
>>> applications and try to get those incorporated back into OFBiz.
>>>
>>>
>>
>> As tempting as this idea sounded to me first(when I started  
>> tweaking with the security stuff), it wouldn't be the right way to  
>> go. For me to push
>> a feature back into the core OfBiz framework, it needs to pass my own
>> scrutiny. The current OfBiz security implementation is just fine &  
>> my custom mods are very specific to our client. So I don't see the  
>> need
>> to put my security implementation back into OfBiz.
>>
>> Given my situation, I'm sure that the 2 chocies I'm left with are
>> 1. Use system login's for services. There is support already built-in
>> 2. Modify the services I'll be using to use my security principles
>>
>> Si, have a look at LoginServices.userLogin, the code actually does  
>> something special with system login's. Let me know what you think.
>>
>> I'm looking for confirmation whether this would be a good way to
>> provide security to services which are not in the realm of the  
>> logged in users security principles.
>>
>> Thanks
>> Ashish Hareet
>>
>>
>>
>>
>> -------- Original Message --------
>> Ashish,
>>
>> Again, just my personal opinion, but I think you've formulated  
>> your problem in a way that permits only one answer.  If you must  
>> keep the core as-is AND you need a different permission structure  
>> for their users, then it seems that the way you've done it is the  
>> only solution.
>> I still think the better solution would have been to change the  
>> permission structure of the core OFBiz applications and try to get  
>> those incorporated back into OFBiz.  You could have avoided  
>> essentially building two security frameworks--one that originally  
>> came with OFBiz, one that you built on top of it which relies on  
>> pushing in arbitrary user logins.
>>
>> This is one advantage of working with open source--you don't have  
>> to keep the core "as is" but can tailor it for your needs or  
>> improve upon it.
>> _______________________________________________
>> Dev mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/dev
>>
>>
>>
> _______________________________________________
> Dev mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/dev
>

 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev