New in 21.1: Dynamic Security Clearance Level Part 1

Good news for security concerned organisations. Finally, its possible to assign different Security Clearance Levels for different organizational conditions, such as devices logged in or network used to login.

Let me explain this using an example.

A company manager called John Doe is regularily working with secret and top secret docs. Therefore he is assigned the highest level of SCL, 100, which allows him to access the most confidential docs of the enterprise, like the canteen menu or so……

All from his normal office with a secured network.

But, when he is on the road, he occasionally is in other offices of the company using the company network. Or even in Home Office, which is a good idea in these times. Here, from time to time he has to check things, but on a lower security level.

Also, from time to time, he wants to have a coffee in some coffee shops. But he wants to hide all information from other guests (maybe Mary Jane?) , so he wants only access to the company intranet docs. This implies an even lower SCL.

How dynamic security levels work

And, of course, he an amend his SCL up to the level originally granted anytime he wants.

How does it work?

At first, it works only with a SAML Identity Provider of any kind. SAML means Security Assertion Markup Language and is an open standard for exchanging data between an identity provider and a service provider.

Wow, sounds like an alien thing.

Not really, we already know OTDS (OpenText Directory Services. And our Content Server (Cluster) is the Service Provider. If a user logs into the Content Server, he is redirected to OTDS, his ID is verified and he can log in the Content Server.

In all cases, the Service Provider has to trust the OTDS.

Logins can be handled in the easiest cases directly from OTDS, OTDS can also utilize any LDAP directory for getting the Verification.

Identity Provider. An example

Next in our chain is the Identity Provider. There are many Identity Providers available, but let’s start with ADFS (Microsofts Active Directory Federation Services).

In this schematic there is the so called “Claims based application” which is OTDS with Content Servers. There must be also any information to tell something abount the user and if he is ok or not. This is dprovided by Active Directory / Active Directory Lightweight Directory Services or any Database or custom storages for the user information.

ADFS is only an example, there are many other Identity Providers avaliable, like Octa, OneLogin, Google, Centrify, Azure, Salesforce, SAP, …….

Here at ADFS there are three things left to do.

  1. define an Access Control Policy

2. Define the rule against attributes

3. Define the Assertion to send

Here, its an example “ID, email, Given Name and Surname” – Rule.

OTDS – Mon amour

In the next post, we’ll deal with OTDS.