IT infrastructures are growing and becoming increasingly heterogeneous. Also, more and more hybrid environments are growing between on-premises solutions and sophisticated cloud-first strategies. Here, data is in the cloud and applications run on-premises or vice versa – or both. One problem accompanies all three scenarios: whoever is active in the network must be identified without a doubt – but how.
Against the background of blurring boundaries between on-premises, cloud and hybrid scenarios, more and more questions arise, such as
Where are the limits of the network?
Which devices connect to which applications?
Who conducts activities out?
All of these are questions in the area of digital identity – and one thing right from the start: Although not only human individuals in the network represent identities, but also devices, applications, websites, and the like, it is not a mistake to start here with humans. If you look at a software stack around the topic of identity and access management (IAM), you should take the perspective for which an IAM platform also stands: namely for the (by no means banal) question of who and what when and why does.
Username And Password Are Any Credentials
People act in many different ways in their digital environments to achieve goals: starting a VPN connection to work remotely, opening a customer account to shop online, and so on. The user cannot do this on his own – so other digital identities help smartphones, tablets, VPN servers, etc. For these to work properly and to do what the user wants, the identities must “know” each other, trust each other and beyond any doubt can interact with each other. For example, when it comes to applications that transport sensitive data, process payments, or the like, it is extremely important that only the identified user can act himself – and not a person who masquerades as this user.
So if a system does not really “know” a user, but only more or less any “credentials” such as username and password, the door is open to identity theft – with all its unforeseeable consequences. Data loss is just as important here as blocking services, injecting malware, and ultimately damaging reputation and customer trust.
Authenticating digital activities through active inputs such as user names and Co. is not identifying. Access is only granted based on an entry – but anyone who knows this access data could make it. If the classic “multi-factors” of authentication are added, the process is moving more towards identification. Two-factor authentication (2FA), which in addition to the access data also asks for a TAN on another device or a physical token, is still not personal. However, if the end device requests a fingerprint to open the TAN or to continue the initiated process, a hard-to-copy, personal factor is included in the access process.
First The Identity Provider Is Controlled Then An Access Token Is Generated
But where in humans an iris scan, face recognition, fingerprint, voice recognition, etc. guarantee personal security: what are comparable patterns when it comes to network devices, machines, algorithms, etc.? The IP address alone and possibly typical connection behavior seem to be a relatively thin basis to guarantee real identification that corresponds to that of a human user.
A very helpful connection can be made between human persons, the devices they use, and, for example, the services they call up. The linchpin here is an identity provider that human users control via their devices. This acts as an agent and the requesting device receives an access token. As a result, there is directory access for the individual – an access manager takes care of corresponding policies, and further access tokens are then tied to this context.
The Identified User Only Makes The Network Component Functional
For illustration, If you look at a restaurant stove with an IoT connection, for example, you will find out that the stove itself, of course, does not know the patterns and characteristics of the individual, individual cook who is standing on the appliance. However, if the cook identifies himself via an identity provider, he will receive access tokens to be able to start up the stove at all. The device only starts to function when the user is identified.