LPC 2.0

  • New rulebased logical engine

  • Reduces implementation time dramatically

IF you spend too much time administrating rights or permissions

LPC is the answer

  1. AIM (Access and Identity Management) webbased solution
  2. Feed and control data for front systems (eg passage)
  3. Rule-based engine for minimum administration
  4. Approvals over web and smart devices
  5. Hosted or on site on customer demand

Contact us for a demo or free trial

Allocation, ordering, approval of permissions

Logical controlled automation

In operation at one of the world’s most technically advanced hospital NKS (New Karolinska Hospital)

LPC 2.0 overall system functionality

Overall structure

 

Terminology

Object

Resources protected from unauthorized access, e.g. Buildings, Areas in Buildings (physical access), IT Systems or objects such as laptops, lockers etc.

Objects can be guarded by an access system e.g. Stanley or individual objects e.g. IT systems. Access to objects is based on permissions.

Subject

Entity requesting to perform an action on an object, for example enter an area or log in to a IT System. In most cases persons.

Persons

Persons are normally integrated with a feeding system AD or any other personal ledger.

Normally persons are found in an OU-structure and can have one or many roles.

 

NPE Nonperson entity

Non-Person-Entity, a Subject not being human such as a IT Service.

Attribute

Characteristics of a subject or object, such as Name, address, training record, job function, etc.

Attributes can be of two kinds:

Informative     no logical impact

Active               can be used in a rule

 Attributes can be created manually.

Attributes can be populated via integrations or manually.

OUs (organizational units) and roles are attributes.

ACM Access control mechanism

Access Control Mechanism. Logical component evaluates the affected rules for a subject and creates a set of permissions for the subject.

A change in the subject’s state or in any of the active attributes will trigger a new evaluation.

The result of the evaluation can be handled in two ways:

  1. Deliver permissions to receiving system or other access controlling system which evaluates the access e.g. Stanley.
  2. On a request from an object to evaluate a RFA (Request for Access)

ABAC Attribute based access control

All active attributes can be part of a rule

Attributes – Rules

Rules are based on attributes.

A ruleset in normally set up for each object.

A ruleset is evaluated in order selected by administrator, and later rules overrides previous.

The order can be changed.

Implementation of rules can be scheduled.

Policy

Rules and relationship that is base for ACM operations.

AMS Access Management System

Access Management System (ACM, Service Portal related interfaces and reports) LPC.

Interfaces

The system will be web based with a user interface and an admin interface.

The admin interface has an extensive internal role-based permission control.

General system functionality

Permissions

Normally based on the receiving objects.

Can be requested if permitted via user the interface.

Can be valid for specified time slots e.g. office hours.

Can have a start and end.

Permissions can have the following attributes

  • Automatic
  • Semi automatic
  • Approval
  • Denied
Automatic

Means that the permission is automatically granted to the subject.

Semi automatic

A request for the permission is automatically created.

Approval

The approval process will be controlled by a workflow which will specify the need for approval (local or central) and control needed attributes for the permission.

Denied

The permission is not visible for the subject (can’t be requested by).

If a permission is denied existing permission will be canceled

Approvals

Are normally based on a cost center.

A cost center has a responsible person.

The responsible person for the cost center can delegate the right to approve.

User and Admin interfaces

Overview of webinterface
  • Admin interface
  • Admin roles
  • Objects
  • Permissions
  • Attributes
  • Roles
  • Organizational structure
  • Customer attributes
  • Rules
  • Cost center
  • Delegation roles
  • Delegation
  • Scheduling
  • Persons
  • Audit
  • User portal
  • My permissions
  • My requests
  • My approvals
  • Show my permissions
  • Request permissions
  • Manage cost centers
  • Administration

AIM

(Access & Identity Management)

The need for companies to have full and direct control over what permissions an employee has is continuously increasing.

For medium-sized to large organizations, this is time consuming and hard to oversee.

As a solution to this problem, LPC was developed in cooperation with NKS (New Karolinska Hospital), where it is currently operational.

LPC

(logical permission control)

LPC handles the logic between an organization’s personnel data and a receiving system. Permissions can be assigned automatically, requested and approved. All functionality regarding these permissions are controlled by LPC’s powerful logical model.

Completely Web-based

  • Administration
  • Ordering
  • Approval
  • Follow-up

Automatic

The basic flow is initiated by a change in the human resources database. Based on the rules information is transmitted to the receiving system.

Implementation

Each new installation involves an implementation project. The new rulebased engine reduces the time to Go live dramatically. Aisle has established cooperation with renowned consultancy firms. Aisle representatives will participate as experts in the project. LPC’s implementation at NKS has given us invaluable knowledge regarding what needs to be done and in which order.

Features

  • Rulebased logical engine
  • Updates of permissions can be planned and scheduled.
  • Personal permission matrix.
  • A person can belong to multiple organizational units
  • A person may have multiple roles
  • The model can be divided into groups for better clarity
  • The recipient of the information can be specified for each individual permission
  • Examples of recipients
    •      Passage
    •      Pneumatic tube systems
    •      Drug cabinets
    •      AD
    •      Other data systems
  •  Each receiver has its own reception method (integration)
  • Customer portal for ordering, tracking and approval
  • Customer perspective
    •      Approved
      •     The request is closed, permission is obtained
    •      Rejection
      •      The request is closed, permission is not obtained
    •      Opportunity to comment in both cases
  • Designated approvers can see current approvals on the portal
  • Approval on 2 levels
    •      Local
    •                Starts from the immediate supervisor (cost center)
    •                May be delegated to one or more people
    •      Central
    •               Specified in permission to one or more people
    •      Is controlled by permissions
    •      Electronical-ID requirements for certain permissions
  • Security
    •      Logging of all system activities (e.g. ISO 20000)
    •      The possibility of logging at database level (HIPAA)
    •      Easy audit interface
  • API for integration with other systems
    •      The ability to integrate with any number of recipients
    •      The ability to integrate with all required data sources
    •      Can be integrated with reporting tools e.g. Xtraction
    •      The base reports are included if the report tool is missing
  • Completely Web-based
  •  Figures from NKSproject
    •      Organizational structure with about 4,000 nodes
    •      25,000 + people
    •      100,000 + assigned permissions
    •      3 receiver SHP, Electronic-Id, pneumatic tube systems
    •      47 roles
    •      40 permissions
    •      9 groups