[KULRICE-5339] Finish integration with presentation controller/authorizer/AttributeSecurity checking KIM Created: 06/Jul/11  Updated: 23/Feb/12  Resolved: 09/Jan/12

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: 2.0
Fix Version/s: 2.0.0-b6, 2.0
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Critical
Reporter: Jerry Neal (Inactive) Assignee: Jerry Neal (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to KULRICE-5183 alternate/additonal DisplayAttributeN... Closed
Similar issues:
KULRICE-14090Make improvements to KIM integration performance
KULRICE-11725Finish KIM RoleDao conversion for JPA
KULRICE-4494Integrate Document Search security with KIM
KULRICE-2121Fix and finish Ignored KIM tests
KULRICE-9157DataDictionaryTypeServiceHelper should check for a null control
KULRICE-7185Optimization of KIM Permission Checks
KULRICE-3946Check KIM relationships for lazy loading
KULRICE-4667Evaluate remote KIM services: analysis & decision
KULRICE-6053Add documentation on "Integrating KIM with other IDM services" to the KIM technical docs
KULRICE-5046Add support for KIM authorization checks to WorkflowFunctions in eDocLite
Rice Module:
KAI Review Status: Not Required
KTI Review Status: Not Required


AttributeSecurity needs to check against KIM to determine whether
whether the security should be applied for the user (mask, partial mask, hidden, readOnly). This needs to integrate with the authorizer.

Here are some tips for finishing the authorization integration:

See BusinessObjectAuthorizationServiceImpl#getMaintenanceDocumentRestrictions and other methods


Create ViewAuthorizationService

Create method #invokeAuthorizerPresentationController in ViewAuthorizationService

1) Invoke Presentation controller to get set of conditionally hidden property names, readonly property names, required property names,
readonly group ids, and hidden group ids

2) Invoke Authorizer to get set of security readonly group ids and hidden group ids, then iterate over each and evaluate the KIM permission. If permission
fails add the group id to the corresponding set found in step 1

3) Apply restrictions to view

Assume the restricted property name is on the object path of the fields binding info, or if blank the view's default object binding path, unless
the property name starts with UifConstants.NO_BIND_ADJUST_PREFIX

Property name can contain a collection name and then a field, in which case the restriction should apply to all fields in the collection with that name

Note only set the corresponding property on the AttributeField is the restiction is enabled, not otherwise (this is so any expression will remain and
still evaluate)

if read only restriction - field.setReadOnly(true)
if hidden restriction - field.setRender(false)
if mask restriction - field.setReadOnly(true) and field.setMasked(true)
if partial mask restriction - field.setReadOnly(true) and field.setPartialMasked(true)
if group hidden - get all attribute fields for group and set field.setRender(false)
if group read only - get all attribute fields for group and set field.setReadOnly(true)

  1. Also, move contents from ViewHelperServiceImpl#invokeAuthorizerPresentationController to new method and move call in performApplyModel
    to after the call to performComponentApplyModel

Create method #checkFieldAttributeSecurity in ViewAuthorizationService

1) Check following

  • if attributeSecurity.isMask() : check field unmask authorization (use dictionaryObjectEntry as data object and dictionaryAttributeName and attribute name)
  • if attributeSecurity.isPartialMask() : check field partial unmask authorization
  • if attributeSecurity.isHide() : check field view authorization
  • if attributeSecurity.isReadonly() : check field modify authorization

Note: Use the dictoinaryObjectEntry for the data object and the dictionaryAttributeName as the attribute name. If not set, use the object given by the view's default
binding path and the property name of the attribute field

Checks should go through the corresponding authorizer

Note special handling needs to be done for collection fields (calling to get additional details)

  1. Invoke in performComponentApplyModel after runComponentModifiers call


Note the presentation/authorizer classes we are working with in krad are located in uif/authorization. The KNS version are located in document.authorization, bo.authorization, and some other packages.

Needs more analysis. In particular for other presentation/authorizer methods and button permissions.

Document well and apply formatting

Comment by Venkat PremChandran (Inactive) [ 10/Aug/11 ]

If I remember correctly, Jerry mentioned in a meeting that he is going to take care of this task. Assigning this back to Jerry

Comment by Jerry Neal (Inactive) [ 28/Sep/11 ]

In addition to this we need to verify we are checking permission like inquire into, maintenance, use screen, and so on.

Comment by Jerry Neal (Inactive) [ 28/Sep/11 ]

Raising the priority since this is needed by KRMS

Comment by Eric Westfall [ 22/Nov/11 ]

Bulk update of incomplete 2.0.0-b2 issues to just a 2.0 fix version.

Comment by Rice-CI User (Inactive) [ 02/Dec/11 ]

Integrated in rice-trunk-nightly #270 (See http://ci.rice.kuali.org/job/rice-trunk-nightly/270/)
KULRICE-5339 some reorganization for pc and auth, starting the view pc
KULRICE-5822 added support for remotable fields on collections

Comment by Jessica Coltrin (Inactive) [ 06/Jan/12 ]

Downgrading to Critical per Jerry's email on 1/4:

I am not really sure I would consider it a blocker though, it is not blocking any development that I am aware of.
This is what I have left for it:

  • Create KIM data (attributes, types, templates, permissions) - currently working on this
  • Attribute security fixing (some bug fixing there)
  • Sub collection view permission
  • Create test cases in sample app
  • Finish javadocs
  • Document and Review with KRAD design group

There are several other items that could be done, but I believe it would be ok to tackle those in 2.2. They are more improvements over how things were done in the KNS. My goal is to have this at a point where we can close it for 2.0, along with KULRICE-5334 by the end of the week.

Comment by Jerry Neal (Inactive) [ 09/Jan/12 ]

Majority of work complete, some further issues will be created for 2.2

Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Generated at Tue Jul 07 00:23:47 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.