system userlogin associated with a party?

[Si Chen-2]

Hi.

We're having some problems doing certain things because the "system"  
userlogin doesn't have a party associated with it.  Should we create  
a "system" Party?  Or should we fix whatever service so that if  
userLogin.partyId == null then don't do what it needed that to do  
(though I'm not sure it'll actually work in all cases that way...)

Best Regards,

Si
[hidden email]

[Adrian Crum]

It would be nice to have the userLogin NOT depend on the Party component.


Si Chen wrote:

> Hi.
>
> We're having some problems doing certain things because the "system"  
> userlogin doesn't have a party associated with it.  Should we create  a
> "system" Party?  Or should we fix whatever service so that if  
> userLogin.partyId == null then don't do what it needed that to do  
> (though I'm not sure it'll actually work in all cases that way...)
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>
>

[Si Chen-2]

There is a lot of code which do things like check the  
userLogin.partyId versus the requested partyId.  Look at  
createCustRequestRole service for example.

On Dec 4, 2006, at 4:59 PM, Adrian Crum wrote:

> It would be nice to have the userLogin NOT depend on the Party  
> component.
>
>
> Si Chen wrote:
>
>> Hi.
>> We're having some problems doing certain things because the  
>> "system"  userlogin doesn't have a party associated with it.  
>> Should we create  a "system" Party?  Or should we fix whatever  
>> service so that if  userLogin.partyId == null then don't do what  
>> it needed that to do  (though I'm not sure it'll actually work in  
>> all cases that way...)
>> Best Regards,
>> Si
>> [hidden email]

Best Regards,

Si
[hidden email]

[David E Jones-2]

In general security checks should follow this sort of pattern:

IFF has General Permission THEN allow
ELSE IFF has Limited Permission and is related to entity with X role  
THEN allow
ELSE IFF logged in user has partyId that equals entity.partyId THEN  
allow
ELSE reject

Not everything will have all of these conditions, but in general  
there should be general/admin permissions that are checked before the  
userLogin's partyId is checked.

Is the createCustRequestRole service the only one you're running into  
problems with or are you finding this as a more general issue?

-David


On Dec 4, 2006, at 5:55 PM, Si Chen wrote:

> Hi.
>
> We're having some problems doing certain things because the  
> "system" userlogin doesn't have a party associated with it.  Should  
> we create a "system" Party?  Or should we fix whatever service so  
> that if userLogin.partyId == null then don't do what it needed that  
> to do (though I'm not sure it'll actually work in all cases that  
> way...)
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>

[Leon Torres-2]

The code in question is as follows (inside createCustRequest service):

<if-compare-field field-name="parameters.fromPartyId" operator="not-equals"
to-field-name="userLogin.partyId">
   <set from-field="newEntity.custRequestId" field="takerMap.custRequestId"/>
   <set from-field="userLogin.partyId" field="takerMap.partyId"/>
   <set value="REQ_TAKER" field="takerMap.roleTypeId"/>
   <call-service service-name="createCustRequestRole" in-map-name="takerMap"/>
</if-compare-field>

If we submit system UserLogin, the service createCustRequestRole fails because
it tries to use a null partyId as a primary key.

Perhaps this piece of code is assuming partyId is always present in UserLogin
and needs to be fixed?

- Leon




David E Jones wrote:

>
> In general security checks should follow this sort of pattern:
>
> IFF has General Permission THEN allow
> ELSE IFF has Limited Permission and is related to entity with X role
> THEN allow
> ELSE IFF logged in user has partyId that equals entity.partyId THEN allow
> ELSE reject
>
> Not everything will have all of these conditions, but in general there
> should be general/admin permissions that are checked before the
> userLogin's partyId is checked.
>
> Is the createCustRequestRole service the only one you're running into
> problems with or are you finding this as a more general issue?
>
> -David
>
>
> On Dec 4, 2006, at 5:55 PM, Si Chen wrote:
>
>> Hi.
>>
>> We're having some problems doing certain things because the "system"
>> userlogin doesn't have a party associated with it.  Should we create a
>> "system" Party?  Or should we fix whatever service so that if
>> userLogin.partyId == null then don't do what it needed that to do
>> (though I'm not sure it'll actually work in all cases that way...)
>>
>> Best Regards,
>>
>> Si
>> [hidden email]
>>
>>
>>
>
>

[Si Chen-2]

Adding the system party is not for validation per se, but rather to  
record data.  It seems that createCustRequest wants to store a  
CustRequestRole to store who took the request.  Should we observe  
that by creating a party for system so that it shows a system party  
took the request?

On Dec 5, 2006, at 9:28 AM, Leon Torres wrote:

> The code in question is as follows (inside createCustRequest service):
>
> <if-compare-field field-name="parameters.fromPartyId" operator="not-
> equals" to-field-name="userLogin.partyId">
>   <set from-field="newEntity.custRequestId"  
> field="takerMap.custRequestId"/>
>   <set from-field="userLogin.partyId" field="takerMap.partyId"/>
>   <set value="REQ_TAKER" field="takerMap.roleTypeId"/>
>   <call-service service-name="createCustRequestRole" in-map-
> name="takerMap"/>
> </if-compare-field>
>
> If we submit system UserLogin, the service createCustRequestRole  
> fails because it tries to use a null partyId as a primary key.
>
> Perhaps this piece of code is assuming partyId is always present in  
> UserLogin and needs to be fixed?
>
> - Leon
>
>
>
>
> David E Jones wrote:
>> In general security checks should follow this sort of pattern:
>> IFF has General Permission THEN allow
>> ELSE IFF has Limited Permission and is related to entity with X  
>> role THEN allow
>> ELSE IFF logged in user has partyId that equals entity.partyId  
>> THEN allow
>> ELSE reject
>> Not everything will have all of these conditions, but in general  
>> there should be general/admin permissions that are checked before  
>> the userLogin's partyId is checked.
>> Is the createCustRequestRole service the only one you're running  
>> into problems with or are you finding this as a more general issue?
>> -David
>> On Dec 4, 2006, at 5:55 PM, Si Chen wrote:
>>> Hi.
>>>
>>> We're having some problems doing certain things because the  
>>> "system" userlogin doesn't have a party associated with it.  
>>> Should we create a "system" Party?  Or should we fix whatever  
>>> service so that if userLogin.partyId == null then don't do what  
>>> it needed that to do (though I'm not sure it'll actually work in  
>>> all cases that way...)
>>>
>>> Best Regards,
>>>
>>> Si
>>> [hidden email]
>>>
>>>
>>>

Best Regards,

Si
[hidden email]

[David E Jones-2]

The if around that looks like a good way to go for now.

We might want to consider a system Party in the future, but in a way  
I think it's nice to not have one because it eliminate the chance of  
accidently messing up certain code, like assuming a user is a party  
and might take part in certain business processes, or possibly have  
certain limited permissions, and I don't think we want to get into  
that at all.

-David


On Dec 5, 2006, at 2:23 PM, Si Chen wrote:

> Adding the system party is not for validation per se, but rather to  
> record data.  It seems that createCustRequest wants to store a  
> CustRequestRole to store who took the request.  Should we observe  
> that by creating a party for system so that it shows a system party  
> took the request?
>
> On Dec 5, 2006, at 9:28 AM, Leon Torres wrote:
>
>> The code in question is as follows (inside createCustRequest  
>> service):
>>
>> <if-compare-field field-name="parameters.fromPartyId"  
>> operator="not-equals" to-field-name="userLogin.partyId">
>>   <set from-field="newEntity.custRequestId"  
>> field="takerMap.custRequestId"/>
>>   <set from-field="userLogin.partyId" field="takerMap.partyId"/>
>>   <set value="REQ_TAKER" field="takerMap.roleTypeId"/>
>>   <call-service service-name="createCustRequestRole" in-map-
>> name="takerMap"/>
>> </if-compare-field>
>>
>> If we submit system UserLogin, the service createCustRequestRole  
>> fails because it tries to use a null partyId as a primary key.
>>
>> Perhaps this piece of code is assuming partyId is always present  
>> in UserLogin and needs to be fixed?
>>
>> - Leon
>>
>>
>>
>>
>> David E Jones wrote:
>>> In general security checks should follow this sort of pattern:
>>> IFF has General Permission THEN allow
>>> ELSE IFF has Limited Permission and is related to entity with X  
>>> role THEN allow
>>> ELSE IFF logged in user has partyId that equals entity.partyId  
>>> THEN allow
>>> ELSE reject
>>> Not everything will have all of these conditions, but in general  
>>> there should be general/admin permissions that are checked before  
>>> the userLogin's partyId is checked.
>>> Is the createCustRequestRole service the only one you're running  
>>> into problems with or are you finding this as a more general issue?
>>> -David
>>> On Dec 4, 2006, at 5:55 PM, Si Chen wrote:
>>>> Hi.
>>>>
>>>> We're having some problems doing certain things because the  
>>>> "system" userlogin doesn't have a party associated with it.  
>>>> Should we create a "system" Party?  Or should we fix whatever  
>>>> service so that if userLogin.partyId == null then don't do what  
>>>> it needed that to do (though I'm not sure it'll actually work in  
>>>> all cases that way...)
>>>>
>>>> Best Regards,
>>>>
>>>> Si
>>>> [hidden email]
>>>>
>>>>
>>>>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>