Connect systems and groups via IDAC
Karolinska Institutet's "Identity and Access system" (IDAC) was implemented in 2019 and constitutes an important function to ensure that "the right person has access to the right authorization at the right time, for the right reasons".
For you who are responsible for systems or groups
More and more systems and groups at KI are being integrated into IDAC to gain better control over their lifecycle management of user accounts and authorizations, but also to be able to follow up assigned authorizations more easily.
Comparison of system connection and group ordering
Depending on the scope of the need and its complexity, the options differ a lot. A system connection with technical integration must define a data flow which can be both trivial and advanced.
The integration determines whether a direct integration can be established or if an intermediary is needed where IDAC writes, and the connecting system reads from. Usually, it is the conditions of the connecting system that set the limits.
In addition to the integration, the administration of the system and its accounts and permissions must be defined. This could be how the system can reuse finished processes in IDAC or if new functions need to be developed.
Depending on the system connection, it can either only concern attestation and follow-up (auditing) of authorizations, or roles, processes and views need to be developed for the administrators of the connecting system to have the right conditions to administer the authorizations for the system.
The groups should be used where the need is not as advanced as a connecting system, even if there are only a few groups that the client wishes to have.
However, if there is a larger number of groups, there are advantages to creating logical applications in IDAC. In these cases, like many others, a dialogue is held with the IDAC administration to find a solution that suits both parties.
Connect your system to IDAC
Connecting your system to IDAC not only gives you as the person in charge better control over accounts and permissions. KI as a government authority also gets higher technical security and control over its IT system, which means that certain attack surfaces against KI are drastically reduced.
In addition to the general security and authorization control that comes with a system connection, you as the person in charge also get easier administration of accounts and authorizations, via IDAC's user-friendly interface and standardized processes and methods. This makes the work more time-efficient where certain parts can be fully automated.
Selection at system connection
In the current solution, there are three connection options to IDAC. These methods currently have no advantage over the other, in other words it is the system that connects to IDAC that in many cases determines the possibilities.
Before a technical integration can be established, the order (the connecting system) and receiver (IDAC management) must ensure a common understanding of the order.
This is done through an initial meeting where agreements on expectations are ensured; responsibilities, prerequisites, development, testing, test environment, schedule, the flow of data, the integration and how this should be packaged in the production environment.
The following connectivity options are available today:
A string of the following format <Application>:<Role >:<Attribute> is written to the IKAT that KI's Identity provider (IdP) consumes. Depending on the requirement to store accounts and permissions in the connecting system, either IdP or KIIP may need to be involved. The string is divided in such a way that application is the system that should connect, role is the role that the user needs and attribute can be the affiliation to a department.
Group and membership are managed by IDAC. In many cases the groups are placed in a new OU but usually not a requirement. The integration can be seen in different ways.
REST, OData, SOAP, SCIM and LDAP can be used. What kind of information is read and written must be clearly defined to minimize risks, however, how the integration needs (as well as should) look.
Connect groups via IDAC
Being able to order and thus manage security groups in AD is one of IDAC's most important capabilities. Currently, IDAC manages a subset of AD with the aim of better lifecycle management of accounts and its access to groups, groups which in turn provide access to other things within KI's IT environment.
These groups’ employees can apply to access where (usually) the owner of the group is expected to approve or deny the request. If an employee ends his work at KI, the account and memberships will be removed.
After IDAC management reviews the order and its needs, a meeting is convened to ensure that the order has been correctly interpreted, and that development can begin.
Typically, IDAC management calls another meeting to present the solution and what responsibilities have been assigned to the owner of the group (also called the resource owner). Depending on the complexity of the order, a meeting may be excluded.
There are different types of orders which depend on the purpose of the groups. Below are some examples that do not exclude other needs:
Project folders are ordered through this form. The form forms the basis for IDAC to be able to create a security group in the AD.
The group is connected to a file space where employees can place documents and other things to make the information available to other colleagues. Employees need to be members of the group to access the file area. If no rules or policies are applied, it is the owner of the group who decides who can access the group (and thus the project folder).
Security groups are a common and well-proven way of assigning access to, for example, applications, servers or software. An example could be that a group is needed to bring together all employees who will have access to sensitive software.
In this case, it is essential that the order contains the necessary information to determine how the group is best created and how it is best administered over time. The sensitivity of the group means that access is tightened, which creates a greater responsibility on the part of those responsible, however or if rules and policies should be applied.
Security groups can also be used to group employees who need extended access locally on a server (not just to reach the server). In this example, a manual handover/connection needs to be done after the creation of the group. These groups are handled in the same way as the above examples.
A common need is to group access to information via affiliations or contexts. These affiliations can be organizational, for example, but also roles and other contexts can be applied.
Currently, IDAC supports the possibility of creating a group and connecting it to an organization. This means that employees who belong to an organization also get access to the group without approval (completely automatically). A major advantage of this is that authorizations persist as long as the employee has an active affiliation with the organization.
The authorization disappears when the employee changes affiliation or ends his work at KI.
Contact and questions
If you have questions or concerns about IDAC and its capabilities or find the order form or the system connection requirements a bit vague, contact IDAC administration through KI Self Service.
We will get back to you as soon as we can via email or via a meeting depending on your needs.