ano-access The new access control system Freitag, 12. April 13 

TOC ‣ What is the ano-access ‣ How does it work ‣ Ontology Freitag, 12. April 13 

What is the ano-access Ano-access is a Component which decides whether an Action can be executed by a User in a Context. Freitag, 12. April 13 

How does it work (1) User User’s Goal ACTION Freitag, 12. April 13 

How does it work (2) ‣ The User - SUBJECT - wants to perform an ACTION on a OBJECT. ‣ In order to achieve it the user has to possess an ALLOW PERMISSION. ‣ This Permission must be contained/granted by one of the ROLES assigned to the user. ‣ Freitag, 12. April 13 

Background user Role executes Permission contains Constraints tied to tied to Action allows/denies has Freitag, 12. April 13 

More technical ‣ An ACTION is something the user can execute or a state he can achieve. ‣ A Permission allows or denies an ACTION. ‣ A Permission only ‘fires’ if its Constraints are fulfilled. Freitag, 12. April 13 

still technical ‣ Permissions are combined to Permission- Sets. ‣ Roles are links (static roles) or copies (dynamic roles) of Permission-Sets. ‣ Roles fire only if their Constraints are fulfilled. Freitag, 12. April 13 

Constraints ‣ Constraints are the most powerful tool of ano- access ‣ With Constraints conditions of whatever complexity can be expressed ‣ Constraints are always working in a context Freitag, 12. April 13 

Constraints For now following constraint types are supported: ‣ Time-based constraints ‣ Credit-based constraints ‣ Custom-constraints Freitag, 12. April 13 

Time-based constraints ‣ Time Interval (absolute) ‣ Day of Week ‣ Time of Day ‣ Next X Units (30 Minutes, 2 Days ...) ‣ Combination of the above Freitag, 12. April 13 

Credit-based constraints ‣ Are active as long as there are credits existent. Deactivate their self upon extinction. ‣ Need an Update Event ‣ Only work with dynamic Roles. Freitag, 12. April 13 

Custom constraints ‣ Can extended nearly without limits. ‣ Can posses special application knowledge. ‣ Work on Object and on Subject. Example: Action: “write_message”, Permission: ALLOW, Constraint: object=woman, subject=man Freitag, 12. April 13 

Roles ‣ Distinguish between dynamic and static Roles ‣ Static roles can be altered after issued. The change affects all users. ‣ Dynamic roles can’t be altered after granted, respectively the change only affects the users since change. Freitag, 12. April 13 

Ontology: Action ‣ Everything the user can execute and the ano- access protect, i.e. write_a_message, start_a_chat, view_profile, view_photo... ‣ Alternatively, the achievement of a state can be expressed by an action, i.e. number of messages in the inbox, number of saved favorites. Freitag, 12. April 13 

Permission ‣ An allowance or a denial to perform an action. ‣ The result of higher prioritized permission overrides the result of lower prioritized permission. ‣ Is only considered if all constraints are met. Otherwise it is ignored. Freitag, 12. April 13 

Constraint ‣ A condition that must be fulfilled to activate the constraint-able object it is tied to (Permission, Role). ‣ All constraints must be fulfilled for a constraint- able to work. ‣ Can be applied to time, object, subject, or credit conditions. Freitag, 12. April 13 

Object, Subject ‣ The executor (subject) and the target (object) of an action. ‣ The subject is usually the user ‣ Object can be a user, but also an item, i.e. mailbox. ‣ Both contain attributes which can be accessed and checked by constraints. Freitag, 12. April 13 

Permission Sets ‣ Collections of Permissions that are used for the Roles ‣ Are linked by static roles -> can be altered later. ‣ Used as blueprints for dynamic roles. ‣ Cannot be tied to constraints. Freitag, 12. April 13 

Roles ‣ Permission assignment to the users ‣ Can be static or dynamic ‣ Can be tied to constraints ‣ Can be used to allow or deny an action ‣ Can be combined at will Freitag, 12. April 13