Part 1: Federated security and identity management
In a traditional on-premise system deployment model, client applications and services reside on the same LAN, or several interconnected LANs, and communicate with each other using domain (or trust) credentials. Once you separate between the services and clients you need to provide a unified way for clients to authenticate and use services outside of their domain boundaries. This is where Federated Security comes handy.
Definition of Federated Security from MSDN:
“Federated security allows for clean separation between the service a client is accessing and the associated authentication and authorization procedures. Federated security also enables collaboration across multiple systems, networks, and organizations in different trust realms.”
Federated identity management is responsible for authenticating user credentials and providing access tokens for accessing resources in c-insight platform. Identities managed by a 3rd party system and created by our operations team on project scope basis. Users use those credentials for interacting with c-insight platform using mobile, web and desktop applications. The component responsible for authenticating user credentials and providing tokens called authorization server and it is cloud vendor agnostic to eliminate vendor lock in. The following diagram demonstrates user login flow:
- Client applications sends credentials requesting access token.
- Authorization server validates credentials against IAM system.
- Once authenticated, access token is issued with user claims and returned to the client application.
- Client makes request for a resource to API Gateway with the issued token.
- API gateway validates presented claims and forwards the calls to the backbone services.
Apart from validating user credentials against IAM system, authorization server adds set of claims used by API Gateway to grant or deny access to user requested resources. The authorization permissions set is fully managed by c-insight platform on RBAC (Role Based Access Control) paradigm and not dependent on 3rd party IAM. This was an essential requirement in order to support both add/update/delete permissions for roles and view/operate permissions for sensors. Each agency in the system controls its sensors and roles defined for the agency provide operative grants on these sensors. RBAC is a substantial topic that can be covered in an article of its own. The main idea is that users assigned to roles which are a group of permissions. Each agency has multiple roles and one super role (agency admin) which configures permissions for roles. Each project has a super user that creates agencies, roles and assigns users to roles and sensors to agencies.
The access tokens provided by authorization server are short lived, encrypted and signed by X.509 certificate. Once the token is created it can’t’ be changed and to add additional claims a new token must be created. We also implemented malicious activity detector which invalidates all issued tokens effectively forcing all connected users to re-login and issue new tokens. Since the token is self-contained, it allows stateless validation of user claims and paves the way to multi-instance deployment of API gateway to support massive number of concurrent users.
Another advantage of federated security is the ability to expose c-insight functionality not only to our client applications, but also to our partners using the platform in a B2B paradigm. In other words, we can create a wide range of user credentials like username/password or username/certificate for diverse connectivity requirements.
When connecting to authorization server, client application must present X.509 client certificate from one of the trusted certificate issuers. Once mutual TLS connection is established between the parties, IAM credentials along with client id and client secret credentials signed and encrypted using client certificate and the whole transport level communication is encrypted using server certificate. These 2 levels of security are vital to ensure message integrity and confidentiality. The following diagram shows how mutual TLS works (courtesy of https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication)
Stay tuned for part 2 in the series where we going to discuss how to use federated security in accessing API and subscribing to notifications.
