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
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