framework release, icky internal dep

[Adam Heath-2]

We've been working toward a framework release.  The framework contains
several webapps, all of which require you to log in.  This is mostly ok,
because the UserLogin table itself resides in framework.

However, there is only a single login available, system, which has no
password, and is disabled.  So no one can access any of the deployed
webapps in base.

ps: setting the password and enabling the system account does work, so
it's probably just a matter of creating a new account just for this purpose.

pps: unless of course we don't want the framework webapps to be
accessible until the applications are installed.

[Adrian Crum]

Related - https://issues.apache.org/jira/browse/OFBIZ-1868


Adam Heath wrote:

> We've been working toward a framework release.  The framework contains
> several webapps, all of which require you to log in.  This is mostly ok,
> because the UserLogin table itself resides in framework.
>
> However, there is only a single login available, system, which has no
> password, and is disabled.  So no one can access any of the deployed
> webapps in base.
>
> ps: setting the password and enabling the system account does work, so
> it's probably just a matter of creating a new account just for this purpose.
>
> pps: unless of course we don't want the framework webapps to be
> accessible until the applications are installed.
>

[David E Jones-3]

We should probably just move the admin account data (the parts that  
are framework specific, ie the partyId and such should stay higher  
level) to the common component or something.

In real life though, this is only useful for demonstration and  
technically no "admin" account should ever exist, only accounts for  
specific individuals. This is a good general practice and necessary  
for things like PCI compliance.

-David


On Nov 19, 2008, at 12:37 PM, Adam Heath wrote:

> We've been working toward a framework release.  The framework contains
> several webapps, all of which require you to log in.  This is mostly  
> ok,
> because the UserLogin table itself resides in framework.
>
> However, there is only a single login available, system, which has no
> password, and is disabled.  So no one can access any of the deployed
> webapps in base.
>
> ps: setting the password and enabling the system account does work, so
> it's probably just a matter of creating a new account just for this  
> purpose.
>
> pps: unless of course we don't want the framework webapps to be
> accessible until the applications are installed.

[Adrian Crum-2]

--- On Wed, 11/19/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: framework release, icky internal dep
> To: [hidden email]
> Date: Wednesday, November 19, 2008, 7:57 PM
> We should probably just move the admin account data (the
> parts that are framework specific, ie the partyId and such
> should stay higher level) to the common component or
> something.
>
> In real life though, this is only useful for demonstration
> and technically no "admin" account should ever
> exist, only accounts for specific individuals. This is a
> good general practice and necessary for things like PCI
> compliance.

Seriously? If you have a framework-only installation, how would you log in to the framework without at least one user login? Even operating systems give you one login to start off with.

I believe the admin user login data should go in the security component.

-Adrian





     

[David E Jones-3]

On Nov 19, 2008, at 11:17 PM, Adrian Crum wrote:

> --- On Wed, 11/19/08, David E Jones <[hidden email]>  
> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: framework release, icky internal dep
>> To: [hidden email]
>> Date: Wednesday, November 19, 2008, 7:57 PM
>> We should probably just move the admin account data (the
>> parts that are framework specific, ie the partyId and such
>> should stay higher level) to the common component or
>> something.
>>
>> In real life though, this is only useful for demonstration
>> and technically no "admin" account should ever
>> exist, only accounts for specific individuals. This is a
>> good general practice and necessary for things like PCI
>> compliance.
>
>
> Seriously? If you have a framework-only installation, how would you  
> log in to the framework without at least one user login? Even  
> operating systems give you one login to start off with.

That may be true of operating systems in days of yore, but these days  
the generally accepted practice is for NO ONE to use the root account,  
except perhaps for low-level system maintenance, and instead use  
"sudoers" and other similar concepts, ie users that have  
administrative privileges. I think it's for the same reason as used in  
PCI stuff, namely funny words like "traceability" and "auditability"  
and "analenablement" (note: one of those three is a joke ;) ).

-David

[Adrian Crum-2]

> From: David E Jones <[hidden email]>
> Subject: Re: framework release, icky internal dep
> To: [hidden email]
> Date: Wednesday, November 19, 2008, 8:23 PM
> On Nov 19, 2008, at 11:17 PM, Adrian Crum wrote:
>
> > --- On Wed, 11/19/08, David E Jones
> <[hidden email]> wrote:
> >
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: framework release, icky internal dep
> >> To: [hidden email]
> >> Date: Wednesday, November 19, 2008, 7:57 PM
> >> We should probably just move the admin account
> data (the
> >> parts that are framework specific, ie the partyId
> and such
> >> should stay higher level) to the common component
> or
> >> something.
> >>
> >> In real life though, this is only useful for
> demonstration
> >> and technically no "admin" account
> should ever
> >> exist, only accounts for specific individuals.
> This is a
> >> good general practice and necessary for things
> like PCI
> >> compliance.
> >
> >
> > Seriously? If you have a framework-only installation,
> how would you log in to the framework without at least one
> user login? Even operating systems give you one login to
> start off with.
>
> That may be true of operating systems in days of yore, but
> these days the generally accepted practice is for NO ONE to
> use the root account, except perhaps for low-level system
> maintenance, and instead use "sudoers" and other
> similar concepts, ie users that have administrative
> privileges. I think it's for the same reason as used in
> PCI stuff, namely funny words like "traceability"
> and "auditability" and "analenablement"
> (note: one of those three is a joke ;) ).

So, if I install a modern operating system, I have no way to log in and create users?

I think there's some confusion here. Here's what you're describing (from my perspective) - I install the OFBiz framework. I want to set up users for the framework. Oops, there is no way to log in to do that. I'm locked out. I can't use the framework.

Operating systems provide the root account so you can create user accounts. Why can't OFBiz do the same?

-Adrian




     

[David E Jones-3]

On Nov 19, 2008, at 11:31 PM, Adrian Crum wrote:

>> From: David E Jones <[hidden email]>
>> Subject: Re: framework release, icky internal dep
>> To: [hidden email]
>> Date: Wednesday, November 19, 2008, 8:23 PM
>> On Nov 19, 2008, at 11:17 PM, Adrian Crum wrote:
>>
>>> --- On Wed, 11/19/08, David E Jones
>> <[hidden email]> wrote:
>>>
>>>> From: David E Jones
>> <[hidden email]>
>>>> Subject: Re: framework release, icky internal dep
>>>> To: [hidden email]
>>>> Date: Wednesday, November 19, 2008, 7:57 PM
>>>> We should probably just move the admin account
>> data (the
>>>> parts that are framework specific, ie the partyId
>> and such
>>>> should stay higher level) to the common component
>> or
>>>> something.
>>>>
>>>> In real life though, this is only useful for
>> demonstration
>>>> and technically no "admin" account
>> should ever
>>>> exist, only accounts for specific individuals.
>> This is a
>>>> good general practice and necessary for things
>> like PCI
>>>> compliance.
>>>
>>>
>>> Seriously? If you have a framework-only installation,
>> how would you log in to the framework without at least one
>> user login? Even operating systems give you one login to
>> start off with.
>>
>> That may be true of operating systems in days of yore, but
>> these days the generally accepted practice is for NO ONE to
>> use the root account, except perhaps for low-level system
>> maintenance, and instead use "sudoers" and other
>> similar concepts, ie users that have administrative
>> privileges. I think it's for the same reason as used in
>> PCI stuff, namely funny words like "traceability"
>> and "auditability" and "analenablement"
>> (note: one of those three is a joke ;) ).
>
> So, if I install a modern operating system, I have no way to log in  
> and create users?

Sure there's a way... creating users has been a part of every OS  
install I've used in recent memory (Linux, OSX, and Windows).

> I think there's some confusion here. Here's what you're describing  
> (from my perspective) - I install the OFBiz framework. I want to set  
> up users for the framework. Oops, there is no way to log in to do  
> that. I'm locked out. I can't use the framework.
>
> Operating systems provide the root account so you can create user  
> accounts. Why can't OFBiz do the same?

Settle down. I didn't say it couldn't I said it shouldn't. You should  
use individual user accounts with admin permissions to create new  
accounts, except the bootstrap account during installation (which is  
usually done through pre-loaded data in OFBiz right now).

-David

[Adrian Crum-2]

--- On Wed, 11/19/08, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: framework release, icky internal dep
> To: [hidden email]
> Date: Wednesday, November 19, 2008, 8:37 PM
> On Nov 19, 2008, at 11:31 PM, Adrian Crum wrote:
>
> >> From: David E Jones
> <[hidden email]>
> >> Subject: Re: framework release, icky internal dep
> >> To: [hidden email]
> >> Date: Wednesday, November 19, 2008, 8:23 PM
> >> On Nov 19, 2008, at 11:17 PM, Adrian Crum wrote:
> >>
> >>> --- On Wed, 11/19/08, David E Jones
> >> <[hidden email]> wrote:
> >>>
> >>>> From: David E Jones
> >> <[hidden email]>
> >>>> Subject: Re: framework release, icky
> internal dep
> >>>> To: [hidden email]
> >>>> Date: Wednesday, November 19, 2008, 7:57
> PM
> >>>> We should probably just move the admin
> account
> >> data (the
> >>>> parts that are framework specific, ie the
> partyId
> >> and such
> >>>> should stay higher level) to the common
> component
> >> or
> >>>> something.
> >>>>
> >>>> In real life though, this is only useful
> for
> >> demonstration
> >>>> and technically no "admin"
> account
> >> should ever
> >>>> exist, only accounts for specific
> individuals.
> >> This is a
> >>>> good general practice and necessary for
> things
> >> like PCI
> >>>> compliance.
> >>>
> >>>
> >>> Seriously? If you have a framework-only
> installation,
> >> how would you log in to the framework without at
> least one
> >> user login? Even operating systems give you one
> login to
> >> start off with.
> >>
> >> That may be true of operating systems in days of
> yore, but
> >> these days the generally accepted practice is for
> NO ONE to
> >> use the root account, except perhaps for low-level
> system
> >> maintenance, and instead use "sudoers"
> and other
> >> similar concepts, ie users that have
> administrative
> >> privileges. I think it's for the same reason
> as used in
> >> PCI stuff, namely funny words like
> "traceability"
> >> and "auditability" and
> "analenablement"
> >> (note: one of those three is a joke ;) ).
> >
> > So, if I install a modern operating system, I have no
> way to log in and create users?
>
> Sure there's a way... creating users has been a part of
> every OS install I've used in recent memory (Linux, OSX,
> and Windows).
>
> > I think there's some confusion here. Here's
> what you're describing (from my perspective) - I install
> the OFBiz framework. I want to set up users for the
> framework. Oops, there is no way to log in to do that.
> I'm locked out. I can't use the framework.
> >
> > Operating systems provide the root account so you can
> create user accounts. Why can't OFBiz do the same?
>
> Settle down. I didn't say it couldn't I said it
> shouldn't. You should use individual user accounts with
> admin permissions to create new accounts, except the
> bootstrap account during installation (which is usually done
> through pre-loaded data in OFBiz right now).

Aha! There's the missing bit of info. So, I can't just download and install the framework, I have to muck around with XML files before firing it up for the first time.

Understood. ;-)

-Adrian



     

[BJ Freeman]

David sounds like you stating Linux or Unix rules.
However the Windows version logs you in as administrator privileges so
you can add software (vista).
They don't force you to have a second login that is not an admin level.

David E Jones sent the following on 11/19/2008 8:23 PM:

>
> On Nov 19, 2008, at 11:17 PM, Adrian Crum wrote:
>
>> --- On Wed, 11/19/08, David E Jones <[hidden email]> wrote:
>>
>>> From: David E Jones <[hidden email]>
>>> Subject: Re: framework release, icky internal dep
>>> To: [hidden email]
>>> Date: Wednesday, November 19, 2008, 7:57 PM
>>> We should probably just move the admin account data (the
>>> parts that are framework specific, ie the partyId and such
>>> should stay higher level) to the common component or
>>> something.
>>>
>>> In real life though, this is only useful for demonstration
>>> and technically no "admin" account should ever
>>> exist, only accounts for specific individuals. This is a
>>> good general practice and necessary for things like PCI
>>> compliance.
>>
>>
>> Seriously? If you have a framework-only installation, how would you
>> log in to the framework without at least one user login? Even
>> operating systems give you one login to start off with.
>
> That may be true of operating systems in days of yore, but these days
> the generally accepted practice is for NO ONE to use the root account,
> except perhaps for low-level system maintenance, and instead use
> "sudoers" and other similar concepts, ie users that have administrative
> privileges. I think it's for the same reason as used in PCI stuff,
> namely funny words like "traceability" and "auditability" and
> "analenablement" (note: one of those three is a joke ;) ).
>
> -David
>
>
>

[Adam Heath-2]

BJ Freeman wrote:
> David sounds like you stating Linux or Unix rules.
> However the Windows version logs you in as administrator privileges so
> you can add software (vista).
> They don't force you to have a second login that is not an admin level.

Er, the unix way is to give you enough rope to shoot yourself in the
foot, then provide better ways.

So, it's up to the end user if they want to do it with full permissions,
or a bunch of hand-holding.

[BJ Freeman]

was not implying that windows policies were better.
only that they don't follow the Unix/linux way of doing things.

Adam Heath sent the following on 11/20/2008 1:04 PM:

> BJ Freeman wrote:
>> David sounds like you stating Linux or Unix rules.
>> However the Windows version logs you in as administrator privileges so
>> you can add software (vista).
>> They don't force you to have a second login that is not an admin level.
>
> Er, the unix way is to give you enough rope to shoot yourself in the
> foot, then provide better ways.
>
> So, it's up to the end user if they want to do it with full permissions,
> or a bunch of hand-holding.
>
>

[Bruno Busco]

Hi,
I am looking into the framework-only to understand what need to be
done to have it working alone.

I have:
1) checked out a fresh SVN trunk
2) deleted the application an specialpurpose folders
3) added
    <UserLogin userLoginId="admin"
currentPassword="47ca69ebb4bdc9ae0adec130880165d2cc05db1a"
passwordHint=""/>
    <UserLoginSecurityGroup groupId="FULLADMIN" userLoginId="admin"
fromDate="2001-01-01 12:00:00.0"/>
  to SecurityData.xml
4) ant run-install
Now I can login to example and webtools applications

How can now add users and set their permissions?

Thank you,
-Bruno


2008/11/20 BJ Freeman <[hidden email]>:

> was not implying that windows policies were better.
> only that they don't follow the Unix/linux way of doing things.
>
> Adam Heath sent the following on 11/20/2008 1:04 PM:
>> BJ Freeman wrote:
>>> David sounds like you stating Linux or Unix rules.
>>> However the Windows version logs you in as administrator privileges so
>>> you can add software (vista).
>>> They don't force you to have a second login that is not an admin level.
>>
>> Er, the unix way is to give you enough rope to shoot yourself in the
>> foot, then provide better ways.
>>
>> So, it's up to the end user if they want to do it with full permissions,
>> or a bunch of hand-holding.
>>
>>
>

[Adrian Crum]

I'm working on the UI for that:

https://issues.apache.org/jira/browse/OFBIZ-1868

-Adrian

Bruno Busco wrote:

> Hi,
> I am looking into the framework-only to understand what need to be
> done to have it working alone.
>
> I have:
> 1) checked out a fresh SVN trunk
> 2) deleted the application an specialpurpose folders
> 3) added
>     <UserLogin userLoginId="admin"
> currentPassword="47ca69ebb4bdc9ae0adec130880165d2cc05db1a"
> passwordHint=""/>
>     <UserLoginSecurityGroup groupId="FULLADMIN" userLoginId="admin"
> fromDate="2001-01-01 12:00:00.0"/>
>   to SecurityData.xml
> 4) ant run-install
> Now I can login to example and webtools applications
>
> How can now add users and set their permissions?
>
> Thank you,
> -Bruno
>
>
> 2008/11/20 BJ Freeman <[hidden email]>:
>> was not implying that windows policies were better.
>> only that they don't follow the Unix/linux way of doing things.
>>
>> Adam Heath sent the following on 11/20/2008 1:04 PM:
>>> BJ Freeman wrote:
>>>> David sounds like you stating Linux or Unix rules.
>>>> However the Windows version logs you in as administrator privileges so
>>>> you can add software (vista).
>>>> They don't force you to have a second login that is not an admin level.
>>> Er, the unix way is to give you enough rope to shoot yourself in the
>>> foot, then provide better ways.
>>>
>>> So, it's up to the end user if they want to do it with full permissions,
>>> or a bunch of hand-holding.
>>>
>>>
>