[KULRICE-4303] Document initiator check fails when KIM is run in remote mode Created: 07/Jul/10  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development, Version Compatibility
Affects Version/s: 1.0.1.1
Fix Version/s: Backlog

Type: Bug Fix Priority: Major
Reporter: Aaron Hamid (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relate
relates to KULRICE-4140 KimTypeInfoService cannot be accessed... Closed
Rice Module:
KNS, KEW, KIM

 Description   

When an application has configured KIM in "remote" mode, permission checks that cross the service bus and occur in the Rice server and that depend on observing client Rice state (such as the document route header for initiator) will fail because client changes have not yet been committed to the database.

For example, RouteLogDerivedRoleTypeServiceImpl.hasApplicationRole:

if (INITIATOR_ROLE_NAME.equals(roleName)){
isUserInRouteLog =
principalId.equals(workflowInfo.getDocumentInitiatorPrincipalId(documentNumberLong));

This will always fail for newly initiated documents, and the result will be that all new documents will be read only (because the current user is not seen to be the "initiator") regardless of any other permission setting.

This is one such example, but it seems like a general problem and could be more widespread (any other state a client may save and the Rice standalone instance may be requested to operate on).



 Comments   
Comment by Aaron Hamid (Inactive) [ 08/Jul/10 ]

Increasing to critical as this is significantly impacting our KFS implementation project.

Comment by Eric Westfall [ 10/Jul/10 ]

I'm not sure how much this is going to take, but I'm going to set to 1.0.3 for now. If it proves too impacting then i'll push to 1.1.

Comment by Eric Westfall [ 10/Jul/10 ]

For documentation purposes, wanted to mention on here that I discussed this with aaron via email, and I think that KIM in embedded mode is the best way for them to proceed in light of these issues as I'm not sure there is an easy solution to this one. I'd like to discuss with the KTI though and see what ideas everyone might have.

Comment by Eric Westfall [ 24/Aug/10 ]

I think this is going to be too much to chew for 1.0.3. Moving to 1.1

Comment by Aaron Hamid (Inactive) [ 17/Sep/10 ]

FWIW we decided to switch to a batch feed integration for KIM identity data with KIM (at least identity service) in embedded mode, so this is not a blocker for us at the moment.

Generated at Sun Jan 24 12:53:14 CST 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.