It’s a general question when a project goes live. Why do you offer this product when X, Y, Z exist in the market already? Here are some points I want to share:
- SPDL language, SPDL stands for Security Policy Definition Language, or Speedle Policy Definition Language (as a recursive acronym). It is basically a plain-English like, declarative policy definition language. For example, “Grant User William Borrow Book; Grant User William Role Admin;”. You understand what the policy defines without any further explanation/commenting. Right? Unlike SPDL, some policy definition languages are based on XML, JSON, or even a particular programming language. It is probably OK if there are not too many policies (say 100 policies or less) in the system. with the policy volume grows, you will feel the pain to understand and manage these policies. It would make system/security administrators’ life easier to use SPDL define policies. I know, I know, one would argue that we could eliminate the complexity by building a powerful policy management system with a beautiful UI. But why not start with a simple approach instead of eliminating the complexity later?
- The ability to handle large volume of policies, how many policies will be created in a system? The intuition of most of us, including myself, is that we don’t need too many authorization policies in a system. Is that true? I can tell you that in my career life I saw more than 4 million authorization policies were created for a single system. It was a bad design for sure. However, nowadays access control is more important than ever before. Systems offer more and more functionalities, they need fine grained access control. And in cloud environment systems serve more users than before. The users are granted with different permissions. No surprise more and more policies will be created in modern applications. Speedle can easily handle a million policies without significant performance degrading.
- REST/gRPC API, well, this is not a special feature of Speedle. Like lots of modern systems, Speedle offers REST/gRPC API. Developers can easily integrate their systems with Speedle through these APIs. for example, invoke REST API to enforce policy check in API implementation.
- Authorization Decision Performance, Speedle achieves millisecond level latency for each ADS call on average. It doesn’t slow down your applications.
- Scalability, in our test environment, an ADS instance may handle 30,000~40,000 calls per second. If you need more power, simply start another instance, the capacity will be doubled immediately. Start two more, the capacity will be tripled, and so on.
- Advanced features, we offer advanced features to extend Speedle, Speedle can understand the tokens issued by GitHub, Oracle IDCS, Google, etc; Speedle can handle the identities from different identity providers… Please check the documentation on https://speedle.io
- Active support from Speedle developers, the team has been working in access control/entitlement management field for 15 years. But Speedle open source project is a newcomer. We don’t have many external use cases for now frankly speaking. We want to promote the open source project. We’ll treat every questions, issues seriously and respond as quickly as we can in our community.