KS Authorization

Weixia (Bonnie) HuangFeb 19, 2013

KIM Basic Concepts

• Namespace -- for us, it’s KS-ENR• Role• Permissions with Permission Details• Add Permissions to Role(s)• Add User(s)/Principal(s) as the member of a

Role• TODO: list links of reference RICE documentation

Permission Templates

• Open View & Edit View• View Group & Edit Group• View Field & Edit Field• View Widget & Edit Widget• Perform Action

Basic Permissions

Open ViewPermission

Edit ViewPermission

Can Access vs. No Permission to Access

User Story: User A can access Manage CO pages while others can’t. • Identify role: Role A • Create permission(s): open view (and edit view permission) with permission details:

viewId=xxx• Assign permission(s) to the role • Add user A as a member of Role A

As CO System Administrator, I need the system to restrict certain users from accessing any Manage Course Offering pages in order to maintain information security and quality.• https://wiki.kuali.org/display/STUDENT/How+to+set+up+the+basic+authorization+for+a+sta

ndard+form+view+--+KSENROLL-3753

Open View Permission

Persons belong to Role Acan access the view

Persons not belong to Role A can’t access the view

ViewOnly/ReadOnly Access vs. Full /Editable Access

User Story: user A is able to successfully perform an action (Create, Modify, Delete) on Manage CO pages while user B can only view the list of COs and AOs but can NOT perform that same action.• Identify roles: Role A and Role B• Identify permissions assigned to each role:

– Role A has open view permission only– Role B has open view and edit view permission

• Assign user A to role A and assign user B to role B

Edit View Permission

Open View Permission

Persons not belong to Role A and Role B can’t access the view

Role A has open view permission but no editview permission, therefore get ReadOnly view

Role B has open view andedit view permissions, thereforeget editable view (full access)

Basic Authorization

Open View Permission

Persons belong to Role Acan access the view

Persons not belong to Role A can’t access the view

Q2: Does a person in Role A get ReadOnly view or editable view?

Edit View Permission

Open View Permission

Persons not belong to Role A and Role B can’t access the view

Role A has open view Permission but no editView permission, therefore get ReadOnly view

Role B has open view andedit view permissions, thereforeget editable view (full access)

Role and Role QualificationUser Story: A user is able to successfully perform an action (Create, Modify, Delete) on a course associated with their assigned administering org. That same user is NOT successful in performing that same action on a course from another administering org different from the one assigned.https://wiki.kuali.org/display/STUDENT/How+to+set+up+a+complex+authorization+based+on+Admin+Org+role+qualification+--+KSENROLL-3755• Identify roles:

– KS Department Schedule Coordinator - Org role– KS Department Schedule Coordinator - Org View Only role

• Identify permissions assigned to each role:– KS Department Schedule Coordinator - Org role has Open View and Edit View permission– KS Department Schedule Coordinator - Org View Only role has Open View permission

• Assign Carol to both roles

Role and Role Qualification (cont.)

• Different Role Types• Role Qualification

• KS Department Schedule Coordinator - Org role

• KS Department Schedule Coordinator - Org View Only role

Permissions Comparison• KS Department Schedule Coordinator

- Org role • KS Department Schedule Coordinator

- Org View Only role

KRAD Layers

• View, Page, Section, Field…

KRAD Layers and Permission Template Layers

View

Page

Section

Field

Action

Widget

Open View & Edit View

KRAD Layers Permission Template Layers

View Group & Edit Group

View Field & Edit Field

Perform Action

View Widget & Edit Widget

Section 1

Section 3

Section 4

Section 5

Section 2

Set up Component level permissions

• Role A has full access to the whole page except for section 2. He only has view-only access for section 2 while Role B has full access to the whole page including section 2

Base setup on view level:Assign Open View and Edit View permissions to Role A and Role B

Overlay component level permission:Assign View Group permission for Section 2 to Role A.Assign View Group and Edit Group permissions for Section 2 to Role B.

Section 1

Section 3

Section 4

Section 5

Section 2

Role A Role B

Example: Seat Pool section turns to readOnly while other sections are still editable

Section 1

Section 3

Section 4

Section 5

Section 2

Set up Component Level Permissions – Flip the coin

• Role A has view-only access to the whole page except that he can modify the section 2 (while Role B has full access to the whole page including section 2 while Role C has view-only access to the whole page.)

Section 1

Section 2

Section 3

Section 4

Section 5

Section 1

Section 3

Section 4

Section 5

Section 2

Role A Role B Role C

Section 1

Section 3

Section 4

Section 5

Section 2

Section 1

Section 3

Section 4

Section 5

Section 2

Set up Component Level Permissions – Flip the coin

Option 1: Base setup on view level:Assign Open View permission to Role A and Role CAssign Open View and Edit View permissions to Role B

Overlay component level permission:Assign View Group and Edit Group permissions for Section 2 to Role A and Role B.Assign View Group permission for Section 2 to Role C

Section 1

Section 2

Section 3

Section 4

Section 5

Role A

Role B

Role C

Section 1

Section 3

Section 4

Section 5

Section 2

Section 1

Section 3

Section 4

Section 5

Section 2

Set up Component Level Permissions – Flip the coin

Option 2:Base setup on view level:Assign Open View and Edit View permissions to Role A and Role BAssign Open View permission to Role C

Overlay component level permission:Assign View Group permissions for Section 1, 3, 4,5 to Role A.Assign View Group and Edit Group permissions for Section 1,3,4,5 to Role B.Assign View Group permissions for Section 1,3,4,5 to Role C

Section 1

Section 2

Section 3

Section 4

Section 5

Role A

Role B

Role C

Section 1

Section 3

Section 4

Section 5

Section 2

Set up Component Level Permissions -- one more tweak

Option 1:Base setup on view level:Assign Open View and Edit View permissions to Role A and Role BOverlay component level permission:Assign View Group permissions for Section 1, 3, 4,5 to Role A.Assign View Group and Edit Group permissions for Section 1,3,4,5 to Role B.

Option 2: Base setup on view level:Assign Open View permission to Role AAssign Open View and Edit View permissions to Role BIf Section 2 is always editable for all roles NO permission checking needed for section 2 set p:readOnly=“false” for all elements in section 2 in view xml file

Section 1

Section 2

Section 3

Section 4

Section 5

Role A

Role B

Search Criteria Section – Override Permission Checking

<bean parent="Uif-InputField" p:propertyName="termCode" p:label="Term" p:labelPlacement="LEFT" p:required="true" p:readOnly="false"> <property name="control">….</bean> <bean parent="Uif-InputField" p:propertyName="inputCode" p:label="Course" p:required="true" p:readOnly="false"> ….</bean><bean parent="Uif-SecondaryActionButton-Small" p:performClientSideValidation="false" p:actionLabel="Show" p:methodToCall="show"/>

Be Careful to Use p:readOnly="@{a parameter }"

• Example: Authz setup is overriden by the feature to display crossListed CO https://jira.kuali.org/browse/KSENROLL-5389

• TODO: – find a good solution to move away to use

p:readOnly for business rule/logic in general.– Or suggest Rice team to make some improvement

for the current design and implementation on View Only?

How KRAD Interpreted View Only permission

• View only permission means open view or view xxx authorization checking returns true but edit view or edit xxx authorization checking returns false.

• For View only permission, by default KRAD– sets p:readOnly=“true” for all input fields. – In collection table:

• automatically hide Actions column (set p:render=“false”??). • According to Jerry, the checkbox column if any should be hidden

by default, but right now it does not – need to report a bug to rice team

– No change on buttons and action links

Default Rendering by KRAD for View Only permission

Desired Rendering for View Only permission

Realize KRAD Limitation

Require permissions setup KRAD Limitation

Section 1

Section 2

Section 3

Section 4

Section 5

Action Links

Buttons

Deal with KRAD Limitation

See https://wiki.kuali.org/display/STUDENT/How+to+disable+buttons%2C+action+links+and+input+fields+when+a+user+only+has+view-only+permission+but+not+edit+permission+on+the+view+level for details

Action Links

Buttons

Option 1: Open View permission for Role AOpen and Edit View permission for Role BPerform Action permissions for buttons and action links for Role B

Option 2 (recommended approach):Annotate view xml based on permission checking result.

Action Links

Buttons

Role ARole A

More…

• Permission Type Service Extension• Permission Template Extension• Support Expression Evaluation• Authorizer extension• Role Type Service Extension

OrganizationHierarchyRoleTypeService• QualifierResolver Extension

OrganizationQualifierResolver

More…

• Maintenance View/Document permission setup– If no component level (Group, Field, Action) permission

needs to be setup, create open document and edit document permissions and assign them to the proper role would work.

– Otherwise, have to setup both document based permission as well as view based permissions for a maintenance eDoc

• See – How to set up the document based authorization for a maintenance

eDoc– How to set up the view based authorization for a maintenance eDoc