GSoSD Review Discussion Point 6: The Role of an Authentication System?

[PerOlofsson-Sinetiq]

The reason for extracting the Authentication from the Authorisation is primarily to keep unrelated functions in different packages.

The Authentication function deals with the task of establishing a verified identity of a user or system. This operation typically occurs at the establishment of a session and will durate for a time. When expiring, the user/system should renew the authentication. The duration might depend on the classification of data, which is out of scope of the authentication, but should be configurable in the service.

There are different ways of establishing the Authentication, for example a username/password, 2-phase login, biometrics or mechanical tags such as RFID. These methods should be interchangeable at a defined service interface to decouple the authentication from other functions such as authorisation.

Currently, there exists some implementations in the industry, such as Swedish BankID and Single-sign-on solutions from Microsoft. Implementations of an Authentication System can be related/tied to the implementation of Authorisation if the situation is preferred.

[emanuelpalm]

The Authentication function deals with the task of establishing a verified identity of a user or system.

Does it handle both users AND systems, or users OR systems? Do we have to separate the two?

In many deployments, users will already have identities via Bank-ID, Active Directory (AD), or some other systems. My suspicion is that systems will not have a priori identities, and there will be no real opportunity to give them Bank-ID or AD identities. Does the authentication system deal with both users and systems in the same way, while leaving integration against existing user identity systems to some other system? Or will there be many different authentication systems that support different user authentication procedures? Can they all have the same basic service interface type, or will there have to be many of those as well?

[borditamas]

AITIA view

The Authentication function deals with the task of establishing a verified identity of a user or system.

Basically there is no need for human user accounts to operate an arrowhead cloud. For the secure communication within an arrowhead cloud we only have to identify the systems, therefore an Authentication System should only deal with the systems (core, support, consumer, provider). If user level authentication is required in a use case, then it could be managed with an other support system.

The Role of an Authentication System?

We think that since the intention is to supoort not only the X.509 certificates, but also other solutions, then an Authentication system should be the only one who has the permission and role to give an identity to a system within a specific arrowhead local cloud. (For example the identity could be some type of certificate or token.)

[jerkerdelsing]

Seams there is a support for having both an Authentication and Authorisation system. Identification of a human user should be yet another system, yet to be concluded.

[PerOlofsson-Sinetiq]

Proposed solution:
There should be an Authentication System available in the core systems. The role of the Authentication System should be to provide and verify identity tokens to any system in the Arrowhead cloud. No user authentication is handled by this system.

[DavidRutqvist]

A bit outside the scope of authentication discussion but why would you want to handle human users and system users differently? After all, both of them are user identities that can have access? From an implementation perspective, it is simpler to not make any difference between identities. If only humans or only systems should have access is up to the authorization system to decide, that trait would be one way the configure authorization rules but there are others so we should not make any distinction here.

This is also the approach other standards have taken, e.g. OAuth 2.0, most IAM solutions etc.

[PerOlofsson-Sinetiq]

A bit outside the scope of authentication discussion but why would you want to handle human users and system users differently? After all, both of them are user identities that can have access? From an implementation perspective, it is simpler to not make any difference between identities. If only humans or only systems should have access is up to the authorization system to decide, that trait would be one way the configure authorization rules but there are others so we should not make any distinction here.

This is also the approach other standards have taken, e.g. OAuth 2.0, most IAM solutions etc.

In theory you are right and I would like to agree with you. However, adding user authentication will most likely incorporate some kind of User registry and I think that is something for a future version of Arrowhead. Version 6,0??
Hence my recommendation is to stay with system Authentication in version 5.0.

[jerkerdelsing]

Per to update the GSoSD.