Piraeus’s architecture is very intentional to reduce the amount of effort needed to leverage the system. The security of the system is built on a concept that an “authority” that can manage resources within the system, e.g., create topics or subscription grains within Orleans. Those grains are ACL’d by access control policies such that only authorized callers can access to those grains. The callers can be anything that can present an authenticated security token where the attributes of the security token comply with the access control policy of the resource being accessed.

The architecture greatly simplifies how Piraeus functions and also reduces latency within the system. The key is access control and how Piraeus manages this. Piraeus puts the user in control of what resources can be access by what callers. It does this through distributed access control policies. These polices can be cached, expired, and renewed by such that they can change within Piraeus without every stopping or redeploying the system. This clean separation of access control management from Piraeus enables to it be both fast and flexible.

One of the new technologies, other than Orleans, introduced in Piraeus is Claims Authorization Policy Language (CAPL). CAPL is a powerful, but simple logic-based and security token agnostic language for access control that enables rapid authorization decisions. CAPL policies can be created externally to Piraeus and then consumed to provide control over resource access, which reduces the complexity and increases the flexibility within Piraeus.

Topic grains within Piraeus include metadata when they are provisioned. Two important pieces of metadata are URIs that reference access control policies for the topic and subscription grains. Piraeus uses these references to return CAPL access control policies to ACL the resources from a service. We call this authorization service, Authorization as a Service, or ZaaS. ZaaS is where the access control policies are managed and Piraeus simply uses the ZaaS policy store to get and update the access control policies for the resources.

We want the access control system to be low latency and as such Piraeus will retrieve the policies when the Topic is provisioned. The policies will be cached locally as well as in Redis. When the policies expire from cache, they will be retrieved again and updated in the local and Redis cache. The Redis cache allows Piraeus to scale its gateways and make the access control polices available to the entire system. Once the policy is retrieved from Redis, it is cached locally to further speed up the process. When the policies expire locally, they are immediately refreshed to the local and Redis cache from the ZaaS service.

The security architecture greatly increases Piraeus’s flexibility because identity and attribute stores are completed separated from the system. Piraeus can scale and be leveraged in multiple data centers without the burden of porting these stores and/or synchronization because of this segregation, something that would be not possible with CAPL.

The benefits of the security architecture actually increase when you consider this clean separation.  Because we are using security tokens with attributes (not connection strings), this means that no caller is trusted, e.g., device, user, etc.  This is more in line with the scale provided by federated identity that is commonly used in Web sites.  Like I say, “If you don’t trust billions of people, then why would you trust devices when they will exceed the number of people on the Internet in the near future.”  The Piraeus architecture builds on this and opens the flexibility on how devices acquire and manage security tokens.  Piraeus does NOT manage devices and provide tightly coupled mechanisms for security token acquisition…by design.  The reason is that scenarios are so diverse for device registration and management that it needs to be either customized or leverage any existing product.  Since Piraeus is not a principal in the identity transaction, it simple requires that security token presented be by a trusted issuer.  Access to resources by the caller are based on the attributes of the security token as executed by a CAPL access control policy.  Again, cleanly separating the issue of token acquisition and management from the Piraeus Architecture.  Roll your own, use an existing product, just present a security token signed by a trusted issuer to Piraeus and it functions securely using CAPL to maintain access control to resources.