Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 52 Next »

Introduction

By default, the CoreOne Suite is deployed with a set of security roles that you can assign to users to perform basic sets of operations. For example there is a Manage Representations security role. If you assign this role to a user, he will be able to see his representations in the CoreOne Self-Service Portal and can delegate some of his responsibilities to others.

This default security role always cover a basic use case and do have some restrictions attached to it. For example the Manage Representations security role only let’s a user delegate something to another Core Identity for which the user first has created a representation. In an eGoverment environment this is a valid use, but in an enterprise environment you might want to enable the user to delegate his permissions to everyone in the company or to co-workers in the same division or any other use case.

This is where the CoreOne Advanced Permission Management comes into place. This optional module allows you to create your own security rules. A security role contain two things, the view permissions and the data access permission. The view permissions are used across all UIs to handle who has access to which views and which actions. The access permissions are used to determinate what data is available to the user or service within the views or APIs. This way you can give certain users access to view and limit them to a subset of the available data.

Built-In Security Roles

Out of the box the CoreOne Suite is deployed with four built-in security roles:

CoreOne Suite Security Role

Access Level inside CoreOne Suite

Available in version

Description

CoreOne Suite Administrator

Full Access

>= 4.0

Full access to the whole CoreOne Suite

CoreOne Suite Approvals

Access to approval requests where the assignee is involved

>= 5.1

Assign this role to users that need to take part in an approval process.

CoreOne Basic Access

General login access

>= 7.0

Allows a user to use his SSO account

CoreOne Suite Computermanagement Admin

-

< 7.0

deprecated

CoreOne Suite DHCP Administrator

-

< 7.0

deprecated

CoreOne Suite Legal Entity Activate

Activate a legal entity button

>= 7.0

Allows a user to activate a legal entity in the CoreOne Self-Service Portal

CoreOne Suite Legal Entity Confirm Changes

Confirm changes to a legal entity

>= 7.0

Allows a user to confirm changes to a legal entity in the CoreOne Self-Service Portal

CoreOne Suite Legal Entity Delete

Access to legal entities in which context the security role is assigned to

Delete rights to legal entities in which context the security role is assigned to

>= 7.0

Allows a user to delete a legal entity for which this security rule is assigned to

CoreOne Suite Legal Entity Edit

Access to legal entities in which context the security role is assigned to

Update rights to legal entities in which context the security role is assigned to

>= 7.0

Allows a user to update a legal entity for which this security rule is assigned to

CoreOne Suite Legal Entity Employment Create

Access to legal entities in which context the security role is assigned to

Create rights to employments in which context the security role is assigned to

Read rights to all employment types

>= 7.0

Allows a user to create new employments for the the legal entity for which this security rule is assigned to

CoreOne Suite Legal Entity Employment Delete

Access to legal entities in which context the security role is assigned to

Delete rights to employments in which context the security role is assigned to

Read rights to all employment types

>= 7.0

Allows a user to delete an employments for the the legal entity for which this security rule is assigned to

CoreOne Suite Legal Entity Register

Read rights to organization unit types

>= 7.0

Allows a user to create a new legal entity in the state of activation pending

CoreOne Suite Manage My Resources

Manage the users resources.

> 5.14

Gives access to all resources where the current user is set as an owner and allows to manage the memberships.

CoreOne Suite Manage My Roles

Manage the users roles.

> 5.14

Gives access to all roles where the current user is set as an owner and allows to manage the memberships.

CoreOne Suite Manage Representations

Full access to representations where he is apart of

Full access to representation relationships where he is apart of

>= 7.0

Allows the user to create and manage representations and delegations

CoreOne Suite OpenID Service

>= 7.0

CoreOne Suite Patch Management Admin

-

< 7.0

deprecated

CoreOne Suite Patch Management User

-

< 7.0

deprecated

CoreOne Suite Shop

Access to see the Shop Module in the Portal

>= 8.0

Gives access to see the Shop Module in the Portal. You still need to configure the appropriate catalogs so that user actually can order things.

CoreOne Suite Self-Service User

Access to the Self-Service Portal

Access to his own Core Identity

Access to his own Identities

Access to orderings and approvals

7.0 > X >= 4.0

Gives users basic rights to perform actions like resetting the password for his own accounts or ordering a role for himself

CoreOne Suite Service Desk

Access to basic Identity Management and Management Features

>= 4.0

deprecated as of Release 7 Can be used to give Service Desk employees basic rights such as seeing all employees, reset passwords and so on.

CoreOne Suite Read Core Identities from Organization Unit

Read access to all core identities that have an valid employment to the ogranization unit in the context or at a child organization unit.

>= 8.0

This security role needs at least one assignment context of the type organization unit.

This organization unit will be used as a root from where you are allowed to read the core identities.

This security role does not give any security rule groups only data access permission to the core identity.

CoreOne Suite Read Assignable Roles

Read access to all roles where you have at least one valid catalog assignment to.

>= 8.0

Allows you to read all roles where you have at least one valid catalog assignment.

This security role does not give any security rule groups only data access permission to the role.

Data Access Permissions

Data access permissions are configured by specifying the entity type, a security mode and a security filter. The entity type defines to which entity, i.e. a Core Identity or a Role, a user has access to. The security mode defines the nature of the access such as read, write, delete or similar. And finally the security filter specifies which conditions have to be met in order to give access. This can be anything from full access to only if a specific condition is met. You will find more on that in the Data Access Permissions section. But it’s important to understand that you can configure security filters based on relations and other attributes of the entity.

Security Roles Pitfalls

As we have learned, the security roles are a powerful tool to build various use cases. But there are a few things that need to be considered.

Performance

The more complex the filter get, the more slower the system will be for the user. If no filter is configured for let’s say roles, the user can be served with the list of roles immediately. But if we configure a security filter that only shows roles to a user that match certain criteria, those criteria have to be evaluated at runtime and therefore will take some time. Depending on the amount of roles, the amount of security filters applied and the complexity of the filters, this may be noticeable to the user.

Maintenance

If you build your own custom use case, you might have to combine a few entity rights to cover your use case. For example if you only want to give read rights to roles that are assigned to a specific organizational unit and the user has a specific employment type, you will not only need to give read rights to the roles, but you will also need to give read rights to the users employments, where the employment type of the user is stored. After an update of the Software it is possible that this data structure has changed. For example the employment type of the user might no longer be stored on the employment but on the Core Identity itself. Even tough such changes rarely happen and are documented in the release notes, there is still a chance. So in order to be sure, you should test each of your security role after each update. When designing security roles, you have to take this into account and plan accordingly.

Relying on default roles

If you use any of our default security roles, you have to be aware that they can change. They are intended to cover a standard use case as described in the documentation. But even though that standard use case might match your use case today, does not mean it will automatically match your use case after an update. We might add some rights to the default security rule that will not match your use case, so you should check the release notes carefully.

Best practices

Testing, testing, testing

It’s vital that you test your security rules after each update. Create a basic test plan for your most crucial cases and execute them after each update.

Blueprints

If you are planning on creating a lot of security roles that only have minor differences, try to extract the common things into a base security rule and only specify the difference in specific security rules. It might also be useful to create a blueprint, test the blueprint after each update and redeploy all specific rules based on the blue print if you have detected any changes.

  • No labels