Discussion: Authentication Core System

[borditamas]

Following the GSoSD Review Discussion Point 6: The Role of an Authentication System? #64

Authentication Core System needs to be designed as soon as possible, because all the other core and supporting systems depend on it in a secure local cloud, therefore we have to have a clear view on how its service(s) should work.

Previously the discussion was about that there should be at least two services (or one service with two operations). One for providing identity to an application system and an other for verifying an identity.

Providing identity

Before using any features of a local cloud the systems have to ask for any indentity which is valid within that local cloud. The systems has to provide implementation specific credentials (X509 cert, identifier & password, etc...). If the credentials are valid, the authentication core system returns a system identifier (this can be the provided identifier or generated or the CN from the X509, etc...) and an identity token. If the credentials are not valid, the authentication core system returns ann error response.

The system should use the returned identifier as the name of the system during all the interactions within the local cloud. Also, every service consumption request has to contain the identity token.

Verifying identity

Before any service response providers should verifying the identity of the requester by calling this service/operation. The input parameters are the requester system's name and its identity token. The possible responses ar OK and error.

The provider should fulfill the service request only if the verification has suceeded.

Our concerns

• How the systems will know the address of the Authentication Core System?
  Obvious answer would be that Authentication Core System is registering its service(s) into the Service Registry, but how the Service Registry will verify the identity of Authentication Core System?
  Is it acceptable if the Authentication Core System directly configurable in the Service Registry Core System?
  Is it acceptable to query the Authentication Core System's service from Service Registry without being authenticated?

• How to avoid identity theft?
  Theoretically a malicious provider could use a received system name and identity token to make service consumption disguising itself to the original requester and stoling its permissions.
  One way to address this problem if the identity token is only sent to trusted components (core and support systems). If an ordinary provider wants to check its consumer it can require token level security in which case an authorization token is needed for the service consumption. Contrary to the identity token, authorization tokens contain the consumer's name, the provider's name, the required service/operation. Authorization tokens are generated by the authorization system which verifies the consumer's identity before returning the authorization tokens.

@jerkerdelsing @PerOlofsson-Sinetiq @emanuelpalm @DavidRutqvist @palvarga

[borditamas]

@AlexChiquito @emanuelpalm @PerOlofsson-Sinetiq
Could you please provide Sinetiq's feedback before the next RoadMap (05.02) in order to being able to discuss it there?
As you know, last time the 14th of May (before AIMS 5.0 GA) was agreed to target the specification being finalized, so we don't have so much time.

[jerkerdelsing]

AITIA to add interaction diagram to further clarify the threat and their proposed solution. From Roadmap WG meeting 240705

[borditamas]

Please see the requested diagram.

• Please note that this describes a use case with a dynamic orchestration from the view of the consumer.
• Of course beside the consumer, every interaction with the core systems from the povider side and even the internal communication between the core systems requires identity tokens, but these are omitted here for the sake of easier understanding.
• The main point here is that the interactions between the consumer and provider does not contain identitiy token in order to prevent any kind of identitiy theft. Identities only shared with the trusted core and support systems.
• The difference between the identitiy and autorization tokens, that while identity tokens identifies a system only, the authetication tokens are represents a consumer-provider service (optionally operation) exchange session.
• Also, having an identiy token is must for all the systems, but requiring an authorization token is a matter of choice of the provider systems.

[borditamas]

The Arrowhead community is admonished to read and review the System Description (SysD) of Authentication v5.0 draft, available here:

• For easier reading, use the .pdf format.
• To reference exact lines use the .tex format.

Please read the document and share your comments and suggestions within this issue.

[jerkerdelsing]

For security we need an encryption of the identity database.
Tokens stored in each consuming microsystem as well need encryption.
Both of these encryption need to be addressed in SysD and further elaborated in SysDD.