Lightweight RBAC for l3AFD

[ajayR006]

L3AF secure webAPI and Authorization requirement is detailed here. The Purpose of this document is to..

1. List the usecase of RBAC requirements for L3AFD API's
2. How to extend x.509 PKI to build lightweight RBAC solution.
3. Discuss new Ideas and compare it with existing framework.

Background

Most people familiar with PKIs will know that the standard format for a public key certificate is specified in the X.509 standard published jointly by the ITU-T and ISO/IEC. The primary purpose of a PKI is to strongly authenticate the parties communicating with each other, through the use of digital signatures. But strong authentication on its own is insufficient for a process to determine who
is allowed to do what. An authorisation mechanism is needed for this.

L3AFD secure webAPI use mTLS for confidentiality and authentication, we need to extend the framework to access control the user with the specific API authorization.
API authorization needs to have 2 roles.

• Admin - Full permission to create, update, read, and delete any configuration element through the API
• Read-Only - Permission to read configuration elements through the API

RBAC alternatives & Frameworks

Option 1. RBAC framework using x.509 PKI Certificate Attributes

Request flow to access l3AFD API to authorize userid “John” with role “web-dev”

Referring to above figure, Workflow of the Authorization phase

1. During the creation of the Client Cert, CN value is specified as a “UserID” in this case “John” And O value is specified as Group or Role, in this case its “Web-dev”

2. Client certificate (X.509 Attribute Cert) is parsed for CN and O attributes at l3AFD service.

3. After parsing this value, the request is sent to “goRBAC” service with API access request details

4. goRBAC service verifies the mapping of userID and Role against API access request, specified as part of authorization request.

5. If the userID and role mapping is True then it checks for Action/permissions allowed for specific API.

6. Based on the permission, goRBAC response is sent to l3AFD server

7. L3AFD server takes actions based the access permission received from goRBAC.

Pros :
1. Extending the existing X.509 mTLS to support Role based Access control
2. No Extra overhead or mechanism between the client and L3AFD service to support RBAC
3. Lightweight service compared to known frameworks like OAuth/OpenID and JWT

Cons :
1. X.509 PMI Implementation for RBAC is not yet dev released which has extended attribute support for Role based Access control.
2. X.509 PKI for RBAC use existing Attributes like CN and OU for access control purpose which is not RFC supported
3. Global CA or Enterprise CA does not support this implementation of RBAC where only close private environment like Kubernetes use this implementation of RBAC.

Option 2. mTLS with OAuth 2.0 Client Authentication

Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources. Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties.

     Mutual-TLS certificate-bound access tokens

    When a client requests a token from the authorization server using mutual TLS, the server can bind the issued access token to the client certificate. The certificate binding is possible either by embedding the certificate hash as a part of the issued token or through token introspection. The access token can be used at the application layer passed as a HTTP header by the client. This makes sure that each request is protected.

Access token as JWT (JSON Web Token)
If the access token is represented as a JSON Web Token, this method can be used to associate the token with the certificate.
this method can be used to associate the token with the certificate. The JWT would include base64url encoded SHA-256 hash of the X.509 Certificate. The JWT contains cnf confirmation method claim. It has x5t#S256 as a confirmation method member that contains the value of the base64url-encoded SHA-256 hash of the X.509 Certificate.

Pros :
1. Use of Preferred industry authorization framework with mTLS authentication layer
2. Extensible to multi-level hierarchy of complex scopes and user groups.

Cons:
1. This is heavy framework which is mainly used for scope delegation and more granular access control
Development of Access token lifecycle, which includes access token allocation, revocation and refresh as part of the authorization service can be avoided through an alternative lightweight framework with basic access control feature.
2. For L3AFD usecase of 2 basic roles for authorization, preferred option to use lightweight framework with basic access control features.

Option 3. Digital Signature based Authorization with mTLS

• First Request is sent to L3AFD Post API for session key
• After the successful mTLS authentication, L3AFD API response share the session key to the user, Here session key = Timestamp
• After the sucessful exchange of session key, Digital sign is created using SHA256 Hash of the <User + Role + Session key> , which is signed by Client Private key
• User shares the , <Digital_Sign> and <User + Role> information during API request flow for specific resource
• L3AFD API service, after mTLS authentication. Decrypt the Digital signature by Client Public key to validate the Integrity & Authenticity of data.
• Hash is validated with the new hash created from Session_Key+user+role by L3AFD Service to prevent the Replay attack threat
• If the hash validation succeeds then User permitted with valid API Response
• if the hash validation fails then 4XX error response is sent back to user.

Pros :
- No need to use Complex framework like Oauth2.0
- It extend mTLS authentication to authorization workflow further using PKI functions.

Cons:
- Learning cycle for user to understand and implement Digital Signature
- Custom Implementation

Option 4. SHA256 Hash based Authorization with mTLS

It has a similar lifecycle to option 3

1. Client Public key hash is created using SHA256 Algorithm.
2. API Request include SHA256_Hash and client certificate.
3. L3AFD API validate the hash by comparing the Hash of client public key.
4. If Hash validation is a success, Hash is forwarded for Authorization flow.
5. Hash is mapped to a role where Authorization response is sent to L3AFD API server.
6. L3AFD API server send the API response or 4XX error based on Permission received from Authorization service.

Pros :
- No need to use Complex framework like Oauth2.0
- It extends the mTLS for authorization workflow.

Cons:
- Learning cycle for user to understand and implement SHA256 Hash of Public key
- Custom Implementation

[ajayR006]

Pros & cons of Options 2 are added now.

[dthaler]

As currently worded, it reads as slightly biased. ("Development of Access token lifecycle, which includes access token allocation, revocation and refresh as part of the authorization service can be avoided through an alternative lightweight framework with basic access control feature.
2. For L3AFD usecase of 2 basic roles for authorization, preferred option to use lightweight framework with basic access control features." is phrased more like "The author likes another option better", not as actual Cons)

I'd recommend we look at a set of ranked evaluation criteria, and how each option meets (or doesn't) those criteria. Such a matrix would present an impartial analysis. For example, I'd say "Reuse mature security code accepted by the industry" or similar wording would be one of the criteria. Option 2 would be Good on that criteria and anything with "Custom implementation" would be Poor on that criteria. Then we can focus the discussion not on the options, but on the relative ranking of the criteria, which keeps the discussion more objective than subjective.

[ajayR006]

I agree @dthaler with your points, we can discuss these points during weekly discussion to further investigate the evaluation criteria where all options has some merits and cons, for example, first option is the way the Kubernetes use the mTLS attributes for authorization and 4th option is standard digital signature based approach. Again we may need to understand the approach which more suits our requirement for access control.

[dthaler]

Here's a possible set of ranked evaluation criteria. Feel free to add to, reword, or argue for reordering:

1. Allows use of existing tools for managing RBAC for other services.
2. Uses existing mature implementation that is widely understood, used, and actively maintained.
3. Extensible (e.g., to support multi-level hierarchy of complex scopes and user groups).
4. Minimize protocol overhead between the client and the L3AFD service.
5. Standards compliant.
6. Minimize overhead (CPU, disk, memory) on the L3AFD host.

[ajayR006]

This is good @dthaler , very aligned with standard RBAC evaluation, Few point i would like to add further.

On Point 3. We may need to discuss more over this during our meeting as It may or may not be aligned with our requirement.
Since one of the main objective considered for L3AFD specific RBAC implementation is to facilitate only 2 Roles for Read-Only, and Admin.

In addition to above points, We can probably consider building an integration layer where Enterprises can integrate there existing Enterprise IAM service with the L3AFD, which would scale from Compliance and Infosec acceptance perspective.

[ajayR006]

Last meeting Summary on option evaluation

Option1 Summary
Negative on 5, 3,1 and 2 Ranked evaluation Criteria, This option is discarded.

Option 2 Summary
4 and 6 on evaluation criteria are weak but all other criteria's are positive.
Since Oauth2.0 is a standard Compliant RBAC, forum was able to relate to it more than other options. forum seems to be more lean on option 2 amongst others.

In addition, few thoughts were discussed on "if we want to build an integration layer which can use existing IAM/Authorization service of any enterprise which is compliant with Oauth2.0"
In this case We may not need to develop the complete Authorization module for Oauth2.0 options. Resource server in our case is l3afd API server and the client side can be developed with Oauth2.0 compliant API interface to be able to integrate with any Enterprise Oauth2.0 compliant authorization service. This will help us to extend Internal Enterprise auth service for L3AFD authorization.

[dthaler]

My understanding of the criteria evaluation for option 3:
1: No
2: Partly (crypto libraries but not the components using them)
3: Partly
4: Yes
5: Partly (as with 2)
6: Yes

[ajayR006]

option 4: 1:N 2:N 3:N 4:Y 5:N 6:Y

[ajayR006]

Consensus from the last meeting on RBAC

1. Option 2 is most preferred option from RBAC design perspective.
2. Current Requirement of L3AFD for access control is very minimal without a need of any complex roles and hierarchy.
3. L3AFD will not take the complete RBAC developement effort rather it would build a recommended solution document for its customer for Intergrating with one of the opensource RBAC solution based on Option 2 design.
4. From open source RBAC integration perspective, L3AFD may consider to develop the integration layer in future based on RBAC solution requirement.

Please comment or add if any of the point is missing.