[FEATURE REQUEST] X.509 multiple roles by certificate fields

[Neverbolt]

Is your feature request related to a problem? Please describe. Given the ability of OAuth to provide different authentication scopes that can be used in Security Requirements it should also be possible to have multiple authentication scopes following specific fields that are specified in X.509 Certificates used for authentication.

Can't it be tackled using specification extensions? As this (in my opinion) is a major feature that improves on the (as of now empty) "X509" Security Scheme Object in a way that does not need any vendor-specific, non-standard components of the used client certificate it should be implemented in the base specification.

Describe the solution you'd like I would like to be able to specify different Roles that can be inferred from a X.509 certificate in a similar manner to OAuth flows, specified as follows:

components:
  securitySchemes:
    certificateAuthorization:
      type: X509
      description: Allows authorization using client certificates
      roles:
        monitoring:
          description: Monitoring Servers, specified by the Organizational Unit in the Subject field of the certificate
          matches:
            Subject:
              OU: monitoring
        streetlight:
          description: A streetlight out in the field, specified by the CN in the Subject field of the certificate, contains two wildcards
          matches:
            Subject:
              CN: "*.streetlight.*.example.com"
        leaderServer:
          description: The leader server, specified by the CN in the Subject field and an the ServerRole Extension field of the certificate
          matches:
            Subject:
              CN: *.servers.*.example.com
            Extensions:
              ServerRole: leader

The matches parameter is hereby optional and acts as a logical AND between its values, meaning that all described conditions need to apply for the role to be given to a client.

The three defined roles can now be used as authorization for servers, or following the (in my opinion important) issue of #418 on an operation basis such as:

channels:
  smartylighting/streetlights/1/0/event/{streetlightId}/lighting/measured:
    description: The topic on which measured values may be produced and consumed.
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
    publish:
      operationId: reportLighting
      message:
        $ref: '#/components/messages/lightMeasured'
      security:
        - certificateAuthorization:
          - streetlight
    subscribe:
      summary: Receive information about environmental lighting conditions of a particular streetlight.
      operationId: receiveLightMeasurement
      message:
        $ref: '#/components/messages/lightMeasured'
      security:
        - certificateAuthorization:
          - leaderServer
          - monitoring
  smartylighting/streetlights/1/0/action/{streetlightId}/turn/on:
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
    publish:
      operationId: turnOn
      message:
        $ref: '#/components/messages/turnOn'
      security:
        - certificateAuthorization:
          - leaderServer
    subscribe:
      operationId: receiveTurnOn
      message:
        $ref: '#/components/messages/lightMeasured'
      security:
        - certificateAuthorization:
          - streetlight

Describe alternatives you've considered I have already considered (and also used) informal descriptions in the description fields, however, this leaves a lot of possibility for automatic verification and it is not possible to sensably generate code from this.

Additional context To actually be useful this depends on #418.

It would furthermore be interesting to use more of the identity to allow even more fine grained access control on a documentation level. An example would be the allowing parameters to be passed to the matches part of the X509 roles like this:

components:
  securitySchemes:
    certificateAuthorization:
      type: X509
      description: Allows authorization using client certificates
      roles:
        streetlight:
          description: A streetlight out in the field, specified by the CN in the Subject field of the certificate, parameters
          parameters:
            customer:
              description: The customer the streetlight belongs to
            streetlightId:
              description: The specific streetlight ID
          matches:
            Subject:
              CN: "{streetlightId}.streetlights.{customer}.example.com"
        leaderServer:
          description: The leader server of a customer, specified by the CN in the Subject field and an the ServerRole Extension field of the certificate
          parameters:
            customer:
              description: The customer the streetlight belongs to
          matches:
            Subject:
              CN: "*.servers.{customer}.example.com"
            Extensions:
              ServerRole: leader

This could then be used as follows:

channels:
  smartylighting/{customerId}/streetlights/1/0/action/{streetlightId}/turn/on:
    parameters:
      streetlightId:
        $ref: '#/components/parameters/streetlightId'
      customerId:
        $ref: '#/components/parameters/customerId'
    publish:
      operationId: turnOn
      message:
        $ref: '#/components/messages/turnOn'
      security:
        - certificateAuthorization:
          leaderServer:
            customer: customerId
    subscribe:
      operationId: receiveTurnOn
      message:
        $ref: '#/components/messages/lightMeasured'
      security:
        - certificateAuthorization:
          streetlight:
            customer: customerId
            streetlightId: streetlightId

[github-actions[bot]]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[Neverbolt]

Note: I would be willing to contribute a pull request when this issue is approved.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation. Thank you for your contributions :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping: It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation. Thank you for your contributions :heart:

[fmvilas]

Hey @Neverbolt. Sorry, I somehow missed this issue. I think it makes total sense to have it in the next version of the spec. I'm now preparing the 3.0.0 Release milestone. Let's make sure we don't forget about this issue after 3.0.0 lands.

Also, you might want to have a look at the new Contributing Guide.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[derberg]

@Neverbolt fyi we start next week meetings related to 3.0 if you want to push it forward

@dalelane something interesting for you I think

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart:

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity :sleeping:

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience :heart: