This is an initial, incomplete draft of possible service clusters, specific services and their dependencies.
The authorization flow is the most important part of our plattform.
Authorization
Authorization is, besides API naming, one of the hardest parts to solve. There are four common approaches for validating a request:
No authorization is necessary e.g. in a shopping cart
A firewall grants access to the trusted subnet
Authorization is being granted by checking an authorization (backend) service (that's how oAuth2 does it)
Authorization is being granted by cryptographically validating an access token (oAuth1)
Let's take a closer look at these four approaches.
No authorization
This approach "do nothing" is not appropriate for enterprise and cloud instances and will receive no further attention.
Firewall
Based on what I heard, the industry standard is not to use an authorization firewall which allows access to the trusted subnet and there are simple and obvious reason for that:
Even if we are in a trusted subnet, it could be possible, that specific commands are run via the command line. In this case, the cmd line would not need any authorization to execute tasks
A firewall can't possibly catch all authorization processes. Sometimes, the context is neccessary to attempt an authorization, sometimes one action needs to check multiple permissions at once (printer.discover & printer.print)
The oAuth2 approach
Having read multiple blog entries by the facebook and netflix devs I have come to the conclusion, that extra network roundtrips are a bad thing in a high performance system. For example see https://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/ that cites Jeff Dean's number for
"Roundtrip within same datacenter 500,000 nsec. " Of course it increases when not in the same subnet. When checking for authorization, we can't proceed to other tasks, instead, we have to wait for our authorization service to respond. However, oAuth2 has been initiated to allow the invalidation of access tokens - which in turn requires a check, if the access token is still valid.
The RAMCloud project might help. In comparison, it "aims to provide end-to-end roundtrips for a key-value store in the same datacenter within “5-10 microseconds,” which would represent about a 100x improvement over the 500 microsecond latency suggested above" by Jeff Dean.
The oAuth1 approach
oAuth1 (in a very simple way) has a cryptographic approach to encrypting tokens. The tokens contain the neccessary information for authentication and don't need an extra network roundtrip. However, invalidating a token is either bound to time (invalidate every X hours) or simply not possible - that's why oAuth2 was started.
The Ory Plattform approach suggestion
What we need:
A way to authorize a request
The possibility to revoke access for specific tokens at any time
A high performance infrastructure, the less network roundtrips the better!
A possible solution would be to do a one time check at the gateway, if the current token is still valid. Once the token passes validation, a cryptographic approach is used in the trusted subnet in order to minimize additional network roundtrips.
However, it is yet unclear how command line usage would work with this gateway approach, since we are already in the trusted subnet in order to execute a command via the command line. But it is unclear, if command line usage is even neccessary - further research on PaaS systems like heroku is neccessary.
If no command line access is required for customers and all actions are performed via RESTful apis, this could be the way to go.
Dependencies
This is an initial, incomplete draft of possible service clusters, specific services and their dependencies.
The authorization flow is the most important part of our plattform.
Authorization
Authorization is, besides API naming, one of the hardest parts to solve. There are four common approaches for validating a request:
Let's take a closer look at these four approaches.
No authorization
This approach "do nothing" is not appropriate for enterprise and cloud instances and will receive no further attention.
Firewall
Based on what I heard, the industry standard is not to use an authorization firewall which allows access to the trusted subnet and there are simple and obvious reason for that:
The oAuth2 approach
Having read multiple blog entries by the facebook and netflix devs I have come to the conclusion, that extra network roundtrips are a bad thing in a high performance system. For example see https://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/ that cites Jeff Dean's number for "Roundtrip within same datacenter 500,000 nsec. " Of course it increases when not in the same subnet. When checking for authorization, we can't proceed to other tasks, instead, we have to wait for our authorization service to respond. However, oAuth2 has been initiated to allow the invalidation of access tokens - which in turn requires a check, if the access token is still valid. The RAMCloud project might help. In comparison, it "aims to provide end-to-end roundtrips for a key-value store in the same datacenter within “5-10 microseconds,” which would represent about a 100x improvement over the 500 microsecond latency suggested above" by Jeff Dean.
The oAuth1 approach
oAuth1 (in a very simple way) has a cryptographic approach to encrypting tokens. The tokens contain the neccessary information for authentication and don't need an extra network roundtrip. However, invalidating a token is either bound to time (invalidate every X hours) or simply not possible - that's why oAuth2 was started.
The Ory Plattform approach suggestion
What we need:
A possible solution would be to do a one time check at the gateway, if the current token is still valid. Once the token passes validation, a cryptographic approach is used in the trusted subnet in order to minimize additional network roundtrips.
However, it is yet unclear how command line usage would work with this gateway approach, since we are already in the trusted subnet in order to execute a command via the command line. But it is unclear, if command line usage is even neccessary - further research on PaaS systems like heroku is neccessary.
If no command line access is required for customers and all actions are performed via RESTful apis, this could be the way to go.
ping @tacurran