'Content' per ROLE for API Gateway

[orubel]

Per Darrel Miller (minus unhelpful commentary)

• Users of OpenAPI descriptions can choose to use to them to drive infrastructure if >they wish. Most API gateways I am aware of simply use OpenAPI descriptions to >assist in performing internal configuration. I have yet to find an API gateway that is >limited in functionality to what OpenAPI descriptions provide.

All OAI MEMBERS use OpenAPI at their API gateway for routing. Routing without checking role related to endpoint means you are not checking 'content' for request/response (see OWASP security issues below)

• OpenAPI allows attaching roles/scopes to operations. This is the same security >capability offered by OAuth2 and Bearer tokens https://tools.ietf.org/html/rfc6750

This is outside of context of mentioned issue (of content and routing) for the intents of what Api Gateways (and OAI members) use it for.

• Users are free to place OpenAPI descriptions behind authorization mechanisms that >do security trimming.

Again, submitted issue has nothing to do with authorization/authentication

• Users are free to define extensions to correlate roles/scopes with schema elements. >This is not a feature that has had significant community support to consider >standardizing. This lack of support for this feature does not create a security >vulnerability.

As shown above, you are misunderstanding issue by relating it to AUTHORIZATION and not ROUTING (which is the REAL ISSUE).This is a misunderstanding of said issue as it has been stated in #1411 again and again.

If you read how people are using it in API Gateway, it is being used for ROUTING TO ENDPOINT POST CHECKING OF SECURITY.

Meaning :

1. Security has been checked
2. Token has been issue
3. Api Gateway now uses OpenAPI to route to endpoint
4. Gateway does a check for request and response data for endpoint using OPENAPI, REGARDLESS OF WHETHER:
   • USER has multiple ROLES
   • Endpoints expect different REQUEST/RESPONSE 'content' per ROLE

OPENAPI assumes an 'anonymous' ROLE (which is issued if no token is found on most systems) and as a result, assumes everyone has this ROLE by default when ROUTING.

This may not be the case when doing the PROCESSING but if it has no way to tell the system that different ROLES should send different request data when ROUTING, it just tells it one thing for everyone.

OPENAPI is promoted for ROUTING at the API GATEWAY both on Swaggerhub and through it many members and as a direct result is in direct violation of several of the OWASP API SECURITY TOP10 rules

• API1:2019 Broken Object Level Authorization
• API3:2019 Excessive Data Exposure
• API7:2019 Security Misconfiguration

A video talking about this issue is here : https://youtu.be/bWVD6Rro04Q

OAI members have admitted on Twitter to using secondary documents at the gateway or NOT DOING THESE CHECKS AT ALL! These SECONDARY DOCS then create another document that needs to syncronize with the API server state (see this video : https://youtu.be/A_Hozpb9gLc ) but does not.

This approach is standard in springboot, spring and django and many other frameworks and languages

As an example, APIGEE shows in this example how to import an OpenAPI doc to do routing but NOT to check the data per REQUEST/RESPONSE : https://docs.apigee.com/api-platform/tutorials/create-api-proxy-openapi-spec

This is mainly because the OpenAPI doc does not provide the request/response content per ROLE so it would not be possible to check post the security check.

[orubel]

So thought I would provide an example of what I am talking about here. So say we have an endpoint where a USER role should only request their own data but an ADMIN ROLE can request anyone they want by sending the UserId.

The USER role should not send a UserId in the request; instead, we get the id from the token.

The ADMIN role can send any UserId they want in the request to get back data.

This would look like this:

paths:
  /user:
    get:
      summary: Returns user info.
      parameters:
        - name: userId
          in: path
          required: true
          description: The ID of the user to return.
          schema:
            type: integer
            format: int64
            minimum: 1.
      requests:
        '200':    # status code
          description: A JSON array of user names
          content:
            application/json:
        permitall: []
          schema: 
                      type: array
            items: 
              type: string
        ROLE_ADMIN: [userId]
          schema: 
                      type: array
            items: 
              type: string

In the above example, 'permitAll' is a catchall for anonymous role (users without tokens) and all other ROLES wherein ROLE_ADMIN defines 'administrative role' and expects request data for that ROLE (concatenating upon permitAll).

This however DOES NOT cover RESPONSE DATA which still needs to be defined in 'parameters' and givene a section under 'content'.

I would suggest defining a 'request' and 'response' section rather than just generic 'content' as it is vague.

The doc does not have a way to check STATE for RESPONSE so that we can use this one doc at all services (api gateway, MQ, etc). DOC is incomplete representation of state in this regard. And thus why it fails one of the security checks.

As an example of a document that provides both REQUEST/RESPONSE data for all architectural instances, see this example : https://github.com/orubel/beapi-all-in-one/blob/master/src/iostate/Person.json

[orubel]

Another reason for doing this is that this creates a 'complete State' document.

Meaning, this document can be used to better:

• syncronize all pieces of the architecture for the request/response (requires separate mechanism at 'central version of truth')
• use to test all endpoints (integration test) from all points of the architecture fo the request/response
• cache state about all endpoints for all points of the architecture

Documents like this are used to automate integration tests so they don't have to be written and also to syncronize all servers from gateways to message queues (see the following)

The only thing that is required is for Openapi to fix ROLES associated to REQUEST data and to address RESPONSE data in the same regard

[darrelmiller]

Thank you for providing a specific scenario that you are trying to achieve. I'm not exactly sure what the difference is between the response from your admin vs non-admin request, but here is a description of what it appears you are trying to achieve.

openapi: 3.0.1
info: 
  title: Example of using Roles to control access to data
  version: 1.0.0
paths:
  /user:
    get:
      responses:
        '200':    # status code
          description: User name based on userid in token
          content:
            application/json:
              schema: 
                type: string
  /user/{userId}:
    get:
      summary: Returns user name of the provided userid
      parameters:
        - name: userId
          in: path
          required: true
          description: The ID of the user to return.
          schema:
            type: integer
            format: int64
            minimum: 1
      security:
        - myScheme: [ROLE_ADMIN ]
      responses:
        '200':    # status code
          description: User name based on the provided Id
          content:
            application/json:
              schema:
                type: string
components:
  securitySchemes:
      myscheme: 
        type: http
        scheme: bearer

In the above example, it turns out that because you chose to use a path parameter to identify the user and because OpenAPI doesn't support optional path parameters, then it is necessary to describe your scenario with two distinct operations.

However, I believe you are also looking for ways to use a single operation and return different response data based on roles. If that is correct, we can iterate on that and show examples of how that might be possible.

[orubel]

@darrelmiller You are STILL missing the point. I could send an ARRAY/LIST of data (thats why I represented it as an array). You are also FORCING encoding in URL; this is considering unsafe practice and does not address sending an array of data.

Also, this assumes a RESTFUL implementation and forces developer to implement your methodology vs DUPLICATING STATE of the backend (which is what OpenApi, RAML and API Blueprint as STATE are meant to do).

Data is normally sent via headers allowing for backend to route the same regardless of ROLE; this is normal backend standard operating procedure for API's.

Finally, the example above is GET. Your example doesn't work with PUT/POST should the roles want to use different data. You are obviously aware of that no doubt.

A solution that states to put everything in URL dictates how the backend needs to work; OpenApi does not dictate how the backend works. It is a REPRESENTATION of the state as it exists. So this solution does not meet goals and needs of community at large due to:

• forcing of one type of encoding for variables (URL vs HEADERS)
• lack of data types for sending variables associated with ROLES (array/list, map, etc) as it is URL encoded
• excessive verbage in that it cannot concatenate data from the 'anonymous' role (should they want to)
• requires different backend mapping/functionality; assumes RESTFUL vs RPC
• this doesn't work for PUT/POST

Thus this FAILS as a solution

An example of usage is below showing request and response data for both roles (permitAll==anonymous) separate from url:

"REQUEST": {
    "permitAll":[],
    "ROLE_ADMIN":["id"]
},
"RESPONSE": {
    "permitAll":["firstName","oauthProvider","username","password","lastName","oauthId","avatarUrl","email"],
    "ROLE_ADMIN":["passwordExpired","accountExpired","accountLocked","enabled","id","version"]
}

This is more full featured as even if data is url encoded, you can still communicate to the system what to expect per ROLE.

You route based on URL but get data based on ROLE. Per the above provided description (if you look in original example), it describes it as so:

'In the above example, 'permitAll' is a catchall for anonymous role (users without tokens) and all other ROLES wherein ROLE_ADMIN defines 'administrative role' and expects request data for that ROLE (concatenating upon permitAll).'

So as you can see, we are trying to route and send different data per role and get back different request data per role.

[orubel]

@darrelmiller Do you have another solution to provide or can this finally be accepted as an issue after almost 4 years of me trying to push this through as a security flaw? This is alot of back and fourth for something so simple.

After all everyone who has security has ROLES and they are associated with the request/response data. Why is this such a hard issue to grock?

I don't need separate servers or endpoints for separate ROLES when they can use the same ones but just request with different data (as the endpoints are using thje same functionality); functionality doesn't change so we use the same endpoint. We only change the endpoint and create a new endpoint when functionality change is required.

This approach is standard in springboot, spring and django and many other frameworks and languages

WHAT YOU SEEM TO BE ASKING (or continuously suggesting) is that the end usewr should create new functionality to meet the needs of state ... which is the tail wagging the dog; OpenApi is GENERATED from the state of the API Server. Hence the API Server is the central version of truth as it contains the 'truth' for all endpoints.

OpenApi state duplicates the data at the central version of truth which is the API SERVER and allows other services to use it (not synchronize to it however... but thats another issue).

[darrelmiller]

After all everyone who has security has ROLES and they are associated with the request/response data. Why is this such a hard issue to grock?

a) That is not true. Not every API uses role based security. b) Just because they do, doesn't mean the impact of roles needs to be detailed in the OpenAPI description to be a secure API c) OpenAPI can associate roles to Operations, you just seem to want to ignore that fact.

I don't need separate servers or endpoints for separate ROLES when they can use the same ones but just request with different data

I never suggested you did. I explained why I created two operations. Your OpenAPI description was invalid for your scenario. I needed to introduce two operations to handle a resource where the UserId was passed in the path and one where it was passed in the token. I also, acknowledged that you probably wanted a scenario with just one endpoint and multiple roles.

OpenApi is GENERATED from the state of the API Server

Nope, that is contrary to the principal of "design first" which is what the API community generally advocates. You're welcome to choose code first, but you will lose many of the benefits of OpenAPI, which may be why you are seeing a misalignment of our goals and yours.

I think it is quite clear to everyone that there is no security flaw, no matter how many times you post the same assertion on Twitter, LinkedIn and Reddit. Secure APIs are written all the time without any OpenAPI description and therefore having an OpenAPI description that you consider incomplete cannot possibly introduce a security vulnerability. An OpenAPI description, is just that. It is a description of an API. Describing an API does not change the behaviour of the API.

[orubel]

a) That is not true. Not every API uses role based security. Can you show some examples as I did? ROLE based seems to be the current default in most languages.

b) Just because they do, doesn't mean the impact of roles needs to be detailed in the OpenAPI description to be a secure API I showed how OWASP disagrees with you and how DEFCON has shown this security issue. Are you saying you are a more knowledgable security expert than DEFCON and OWASP?

c) OpenAPI can associate roles to Operations, you just seem to want to ignore that fact. Your example did not show that. I explained the issues with your example in detail.

I don't need separate servers or endpoints for separate ROLES when they can use the same ones but just request with different data

OpenApi is GENERATED from the state of the API Server

Nope, that is contrary to the principal of "design first" which is what the API community generally advocates. You're welcome to choose code first, but you will lose many of the benefits of OpenAPI, which may be why you are seeing a misalignment of our goals and yours.

I don't care if it is contrary to design first. The endpoint and the data associated to the endpoint is what you are mocking. And that is associated with the app.

So you are NOW saying that the OpenAPI doc generated by the app dictates the state of your code??? That regardless of your annotations and your hardcoded data, OpenApi is the defacto state???

That OpenApi generates your codes state and not the other way around???? Correct me if I am wrong here but that seems to be what you just stated.That is the tail wagging the dog or the cart saying that it drives the donkey.

You MIGHT be able to say that if there was a separation of state from function in your code so that you could do things like this but until then your not even close and would STILL NEED to have ROLES associate with your data to have a level of atomicity that the doc lacks.

I think it is quite clear to everyone that there is no security flaw, no matter how many times you post the same assertion on Twitter, LinkedIn and Reddit.

You seem very sure of this. Would you care for a live demo? I'll gladly show how using openapi in a live demo from a generated doc how it will not send correct request / response data.

I'll create a series of tests. I'll show all the code. Any objections??? I'll even let YOU supply the OpenAPI doc with all the endpoints (since you believe that OpenApi DICTATES the state of the app). Sound good?

[darrelmiller]

I showed how OWASP disagrees

No, you have referenced OWASP issues that are only tangentially related. I believe you have misunderstood the scenario what they are describing.

DEFCON has shown this security issue

Perhaps you can find someone else who can describe the problem for you, because to-date, your arguments are unconvincing.

The endpoint and the data associated to the endpoint is what you are mocking.

When a tool decides to use OpenAPI descriptions for mocking, then yes, OpenAPI is used for mocking. When an OpenAPI description describes a production API, it is not being used for mocking. My assumption has been that you are trying to describe security issues with production APIs, not mock APIs.

So you are NOW saying that the OpenAPI doc generated by the app dictates the state of your code

No, I am not saying that at all. I recommend that users of OpenAPI either hand write their descriptions, or use tools designed for creating OpenAPI descriptions to create those descriptions. We recommend those descriptions be created before any implementation code is written. OpenAPI descriptions are just as valuable an artifact during the design process as they are for augmenting the runtime experience.

That OpenApi generates your codes state and not the other way around????

I'm not sure where you got that impression. I don't see anything in what I wrote that would lead you to that conclusions. Some people do use OpenAPI descriptions for scaffolding API implementations, but those are, by definition only partial implementations of an API.

you believe that OpenApi DICTATES the state of the app

No I don't believe this and I have never said anything close to this. While you continue to invent strawmen to tear down, I don't think we are going to make any progress.

The assertion that there is a security flaw in OpenAPI because someone can implement an insecure API that the OpenAPI describes, is equivalent to saying there is a security flaw in a programing language because it can write insecure programs.

An OpenAPI description describes a set of HTTP interactions that are possible with an API. There is no requirement that the OpenAPI description be an exhaustive description. The API will behave in ways beyond what is described in the OpenAPI description. The layered architecture of HTTP guarantees that. It is also true that just because a JSON Schema model says that a property may exist in a response, does not guarantee that it will. Security concerns, that may be based on roles could choose to exclude certain properties. There is no requirement that OpenAPI describe this additional security.

If you build API infrastructure that depends on an API description exhaustively describing the behaviour of an HTTP API you are going to find OpenAPI is not the right tool for you. You will probably find WSDL a better fit.

[orubel]

No, I am not saying that at all. I recommend that users of OpenAPI either hand write their descriptions, or use tools designed for creating OpenAPI descriptions to create those descriptions. We recommend those descriptions be created before any implementation code is written. OpenAPI descriptions are just as valuable an artifact during the design process as they are for augmenting the runtime experience.

Oh you mean DESIGN MOCKS. You can't implement MOCKS. So again... The API Server ENDPOINTS ARE the central version of truth in a PRODUCTION / WORKING SYSTEM. OpenApi / RAML /API Blueprint were all duplicate state so as to share in a distributed architecture. Why are you trying to have this argument? It's like you are trying to argue just to argue.

RAML / API Blueprint / OpenApi are all duplications of state so as to share with other architectural instances. Sure you can MOCK them in the DESIGN PHASE but it means nothing as you still have to implement and once implemented in the application, you generate the RAML / API BLUEPRINT / OPENAPI file base on the Api Applications central version of truth.

The fact that you would even iimply that OpenApi (or that MOCKS) is the central version of truth is a bit silly.

An OpenAPI description describes a set of HTTP interactions that are possible with an API

Actually, if you want to be exact , the doc should 'enable':

• synchronization across all architectural systems that share the request/response
• testing across all architectural systems that share the request/response
• secure call flow across all architectural system that share the request/response

I find OpenApi doesn't meet ANY of the above. But since you are pushing it as a standard for all the above, I am wanting to help you to improve it so it can be. But yopu seem to believe it already meets all these and have stated in #1411 that you refuse to work with me. So I tend to believe you are still just being argumentative.

But AGAIN... I offer to run a demo of how these flaws exist if you supply the openapi doc. I'll write all the code. Can we agree?

[darrelmiller]

An OpenAPI description describes a set of HTTP interactions that are possible with an API

Actually, if you want to be exact , the doc should 'enable':

• synchronization across all architectural systems that share the request/response
• testing across all architectural systems that share the request/response
• secure call flow across all architectural system that share the request/response

LOL. I tell you what OpenAPI is designed to do. You tell me I am wrong, despite me having worked on the spec for the last four years. Then tell me what you think it is designed to do and then tell me how bad it is at doing what you think it should do.

Owen, you are looking for an orange and we designed an apple. I highly recommend that you stop trying to use OpenAPI for what you are trying to achieve.

Peace.

[orubel]

I'm going to point something else out that I was going to surprise you with later but may as well just get it over with now.

Take a look at the OpenApi schema for security in association to your 'uri':

    get:
      summary: Returns user name of the provided userid
      parameters:
        - name: userId
          in: path
          required: true
          description: The ID of the user to return.
          schema:
            type: integer
            format: int64
            minimum: 1
      security:
        - myScheme: [ROLE_ADMIN ]

The parameters are NOT associated with the ROLE

I could call get > security > myScheme but the parameters are NOT associated. I was TRYING to point this out when I stated you were URL encoding everything; it was implied but you didn't see that so I was just going to spring this on you later.

Now. The PROPER way to do this is to have an association with the role (even if there isn't a role):

"/show": {
    "METHOD": "GET",
    "REQUEST": {
        "permitAll":[],
        "ROLE_ADMIN":["id"]
    },
    "RESPONSE": {
        "permitAll":["firstName","oauthProvider","username","password","lastName","oauthId","avatarUrl","email"],
        "ROLE_ADMIN":["passwordExpired","accountExpired","accountLocked","enabled","id","version"]
    }
...

BOOM! Now we have the association and can get them even if the user doesn't have a token and is an anonymous user.

[orubel]

An OpenAPI description describes a set of HTTP interactions that are possible with an API

Actually, if you want to be exact , the doc should 'enable':

• synchronization across all architectural systems that share the request/response
• testing across all architectural systems that share the request/response
• secure call flow across all architectural system that share the request/response

LOL. I tell you what OpenAPI is designed to do. You tell me I am wrong,

I don't believe I said you were wrong... I merely added my own take. You see. And this is from studying RAML / API Blueprint AND OpenAPI. Yours is just ONE doc of many that is trying to reach an ideal of shared state and has yet to achieve it.

... and then tell me how bad it is at doing what you think it should do.

Um ... we are in 'issues' man. This is the place. And you cant take it personal. You have to understand that everything changes and improves. And I may be the guy NOW saying something but its not a reflection on YOU.

You shouldn't be taking offense at this. This is not a personal conversation but a technical one. Please treat it like one. I merely gave a technical response.

I think this is where you are getting off track in that this is becoming personal for you. For me this is a technical discussion and I want it to remain technical.

[darrelmiller]

Actually, if you want to be exact , the doc should 'enable':

This statement infers that you are being exact and I wasn't. I believe you are the one who is making this personal.

As far as I know "achieving shared state" is not a goal.

I am well aware of your desire to correlate roles with data elements. But you keep getting distracted by the state synchronization story.

I've never disputed that correlating data elements in a payload with roles might be useful. It is an extension that I need to investigate because I may need it for my own work.. Where we disagree and keep getting stuck on is the fact that not be able to describe that connection isn't a security flaw.

I didn't take offense, I told you that you seem to be trying to use OpenAPI for something it isn't designed to do.

If you can focus on mapping on roles to payloads, I am prepared to engage. I'm not interested in talking about "shared state" and "state synchronization" as it isn't relevant to the OpenAPI specification.

[orubel]

This statement infers that you are being exact and I wasn't. I believe you are the one who is making this personal.

Only if you want to interpret that way.

I've never disputed that correlating data elements in a payload with roles might be useful. It is an extension that I need to investigate because I may need it for my own work.. Where we disagree and keep getting stuck on is the fact that not be able to describe that connection isn't a security flaw.

Well its nice that you MIGHT need it for YOUR WORK. A couple thousand projects already USE IT FOR THEIR WORK. Are you saying they should just all wait around until YOU DECIDE until you find it useful???

Previously you said OpenApi handled this. I just showed that it didn't. Now you say you MIGHT find this useful someday???? Well which is it? Does OpenApi do this or not??? And if it does, how does it get past the association issue I just pointed out above?

As far as I know "achieving shared state" is not a goal.

So you are saying you are WANTING OpenAPI to be in a different STATE than the API Endpoints?????

If you can focus on mapping on roles to payloads, I am prepared to engage. I'm not interested in talking about "shared state" and "state synchronization" as it isn't relevant to the OpenAPI specification.

Again, are you saying OpenApi isn't meant to sync with the API endpoints? That it is MEANT to be in a different state????

[darrelmiller]

Previously you said OpenApi handled this. I just showed that it didn't.

I said OpenAPI can correlate roles to Operations. OpenAPI currently doesn't have a way to correlate Roles with data elements. It probably never will because the extension is most likely going to be an extension to JSON Schema, not OAS. Your example is overly simplistic because it only shows simple properties in a response. That's not going to be sufficient when the payload contains nested objects.

Are you saying they should just all wait around until YOU DECIDE until you find it useful???

If you had read carefully you would have seen I said "extension". Anyone can add extensions. That's how we recommend people prototype new features. By creating extensions that solve the problem. Literally all you have to do is add x- in front of the property you think is missing. If it solves the problem and tooling adopts it, then it is really easy for us to add it to the spec.

Why are you taking offense at my suggestion that one of your requests holds merit?

So you are saying you are WANTING OpenAPI to be in a different STATE than the API Endpoints?????

That's not what I said. You are creating another strawman. Your use of the word state is very ambiguous. This is why we stopped talking 3 years ago. You use words in ways that mean specific things to you, and you assume other people share that understanding.

As I said, I'm not interested in debating what "synchronizing state" means to you. The information that is contained in an OpenAPI description should be accurate. However, the API may have behavior that is not described in in the OpenAPI description.

[darrelmiller]

BTW, regarding this example,

"/show": {
    "METHOD": "GET",
    "REQUEST": {
        "permitAll":[],
        "ROLE_ADMIN":["id"]
    },
    "RESPONSE": {
        "permitAll":["firstName","oauthProvider","username","password","lastName","oauthId","avatarUrl","email"],
        "ROLE_ADMIN":["passwordExpired","accountExpired","accountLocked","enabled","id","version"]
    }

Here's one way you can get close to that with OpenAPI. This example is using a POST to allow sending the different payloads based on role. Content objects can have multiple media types that differ only by parameter.

openapi: 3.0.1
info: 
  title: Example of using media type parameters to correlate roles to payloads
  version: 1.0.0
paths:
  /show:
    post:
      requestBody:
        content:
           application/json;role=anonymous:
            schema:
              type: object
           application/json;role=admin:
            schema:
              type: object
              properties:
                id: {}
      responses:
        '200':    # status code
          description: User name based on userid in token
          content:
            application/json;role=anonymous:
              schema: 
                type: object
                properties:
                  firstName: {}
                  oauthProvider: {}
                  username: {}
                  password: {}
                  lastName: {}
                  oauthId: {}
                  avatarUrl: {}
                  email: {}
            application/json;role=admin:
              schema: 
                type: object
                properties:
                  passwordExpired: {}
                  accountExpired: {}
                  accountLocked: {}
                  enabled: {}
                  id: {}
                  version: {}

In theory we could do this as a GET if you used a header for the inbound role. We have never recommended using multiple media types with a content property for a header before but I don't think we actually prevented it.

[orubel]

That's not what I said. You are creating another strawman. Your use of the word state is very ambiguous

Not really. As I said, 'state' is the following:

• synchronization across all architectural systems that share the request/response
• testing across all architectural systems that share the request/response
• secure call flow across all architectural system that share the request/response

Pretty simple to understand I think.

But ok @darrelmiller ... lets look at some of the things you have stated...

As far as I know "achieving shared state" is not a goal.

So you seem to understand 'state' ok here. You even claim that it's not the goal of the OpenApi project.

I'm not interested in talking about "shared state" and "state synchronization" as it isn't relevant to the OpenAPI specification.

Again, you dont seem to have a problem understanding it again and again state it isn't the goal of the OpenApi project.

OpenApi is GENERATED from the state of the API Server Nope, that is contrary to the principal of "design first" which is what the API community generally advocates.

Here is where you get confused. You believe that the DESIGN MOCK generates OpenAPI. Here I will tell you that you are wrong and that a PRODUCTION / WORKING API APPLICATION is what generates the doc... otherwise you are STUCK writing it by hand.

You are all over the place, man. Making contradictory statements. I'm waiting for you to land on something and stick to it.

If you disagree, I think you should inform people what it is you ARE creating then. I myself am now SERIOUSLY confused as to what it is you are trying to create.

[orubel]

application/json;role=admin

well not ideal; this means that if I'm interpretting for multiple formats, I have to now put that data in for each different format???

So if the 'endpoint' automagically transforms XML requests and JSON requests on the fly, I would still have to put all that in to the document and create separate endpoints in the OpenApi doc for each and every URI and its corresponding format and role.

Format really only matters for a functional interpretter / transformer thus it's really all function

But if content-type / accept are to be associated, it would be higher up and most likely not here as this would be redundant.

Don't you think?

[darrelmiller]

Sorry Owen, I give up. OpenAPI has the extensibility to do what you need. There is plenty of content out there that explains what contract first or design first actually means. I've already spent my evening trying to help and now you are gaslighting.

I hope you are able to achieve your goals. But I'm confident you don't need my help to do that.

[orubel]

@darrelmiller During this thread I have seen you jump from one excuse to the next.

This issue has been on your plate for close to 4 years!

You are offering a quick fix of associating roles with formatting??? No it's not gaslighting, it's calling it what it is... a poor quick fix for something that has been on your plate for nearly 4 years!

You are frustrated because I am pointing this out? Well are you asking people NOT to point out issues in a standard?

Because this is how things improve and get better. This is how we all improve and get better.

[darrelmiller]

You do realize that nobody working on the OpenAPI specification is paid for what they do? We all work on this in our free time. Nobody owes you anything.

OpenAPI work is prioritized based on impact and community contributions. One person wanting a feature doesn't get a higher priority than features that many users are asking for.

Creating a smear campaign that spreads FUD and sending threatening emails, to try and pressure volunteers to do work so that your product architecture can work with OpenAPI is not the most effective way to go about achieving your goals.

[orubel]

You do realize that nobody working on the OpenAPI specification is paid for what they do? We all work on this in our free time.

Alot of my work is the same

Nobody owes you anything.

True. Nobody owes ME. When we work on open source, we owe our users and become indebted to our users. And when we try to become a STANDARD, it is even MORESO TRUE. This is why it is SO IMPORTANT that we ask for help when we need it.

OpenAPI work is prioritized based on impact and community contributions. One person wanting a feature doesn't get a higher priority than features that many users are asking for.

I think you seem to be under the impression that this wasn't brought up around 2017. That we didn't have this conversation about 4 years ago??? That you are somehow suddenly surprised and unaware of this sudden interest in security.

You also seem to think that I am the only person doing this when I pointed out that this is a documented feature in Spring, Springboot, Django and others??? Talk about strawmen... geez. Right there thats thousands of developers dude.

Creating a smear campaign that spreads FUD and sending threatening emails

Threatening email??? Ooooh... you mean 'OPEN LETTER TO OPENAPI' : https://twitter.com/BeApi_io/status/1318260623902347264

Which only came After Ron Ratovsky (@webron) openly mocked and then deleted his comments on Twitter : https://www.linkedin.com/posts/orubel_openapi-security-flaws-activity-6724378558250278912-QJWy

I apologize if you felt threatened by that. I myself felt humiliated by Ron's actions and your community's ongoing lack of response but it did get you to be responsive... unfortunately, not to listen or be productive.

[orubel]

@darrelmiller And BTW, one man cannot possibly bring an entire specification to an end; that would require years of negligence, not merely one api researchers word. I'm pleased you would give me credit for wielding so much influence but regardless of conspiracy theories, I am not that powerful.

I merely would like to see the spec take a 'secure by default' stance.

It is easy to remove security features when they are not needed but enforcing them by default should be the standard in any schema.

[LikeLakers2]

Hi orubel, it's me again.

I would suggest you drop the issue, and go somewhere else. Clearly OpenAPI is not going to work how you want it to work. So stop frustrating yourself and go to another repository that enjoys your ideas more. Don't dedicate your life to a lost cause, please -- alongside being a waste of your time, it's bad for your mental health.

If you really want your API description to include what roles can produce what results, consider using Specification Extensions as has been suggested on multiple occasions. Otherwise, maybe use BeAPI (as you already are), since you seem to have a much better time with it, and since it already supports this mechanism.

[philsturgeon]

Your lawsuit sounds frivolous and stupid. Please give up and go away. You’ve been ranting at people about things that are half completely unintelligible, half provably false. I’m sure if I wasted enough time taking to you the unintelligible part would turn out to be false too.

We’ve all wasted enough time trying to be polite to you, it’s been years now, so don’t throw a wobbly when somebody calls you out as threatening. You know what you’ve done to hurt and scare people in the API community, and so do I. Drop it. Use your energy for something constructive, take up golf, doesn’t matter, just leave this community alone.

[orubel]

Your lawsuit sounds frivolous and stupid. Please give up and go away.

@phil I never said there was a lawsuit. And I finally know what @darrelmiller is talking about. It was an openletter to OpenApi : https://twitter.com/BeApi_io/status/1318260623902347264

Which only came After Ron Ratovsky (@webron) openly mocked and then deleted his comments on Twitter : https://www.linkedin.com/posts/orubel_openapi-security-flaws-activity-6724378558250278912-QJWy

You’ve been ranting at people about things that are half completely unintelligible, half provably false.

And you think 'shared state' is completely unintelligible??? Ooooook. This says more about the contributors to the spec than it does about me if few of you can understand that the 'state' of the endpoints needs to be shared and synchronized in a distributed architecture. I was able to have this conversation easily with the API manager at Netflix in 2015 and he stated 'this fixes everything we are currently having issues with'.

So I have no idea why the creators of a spec for the entire industry are having such a hard time groking such a basic concept.

We’ve all wasted enough time trying to be polite to you, it’s been years now, so don’t throw a wobbly when somebody calls you out as threatening.

Its nice to know that you find being polite a waste of time. I do not. Especially when helping others. You actually are doing more to show the lack of professionalism that I pointed out in the project.

You know what you’ve done to hurt and scare people in the API community, and so do I. Drop it. Use your energy for something constructive, take up golf, doesn’t matter, just leave this community alone.

"First they ignore you, then they laugh at you, then they fight you, then you win." - Ghandi

[LikeLakers2]

Hi orubel. I will make my suggestion once more, and I'm hoping this time that you will listen, for your own sake.

Please leave this topic alone. If you wish to admit victory in the background, that is your own doing, but you are quite honestly making a fool of yourself... what with all the bolding, capital words, and even quotes that you have mis-attributed. Not to mention that, despite having four other closed issues, you decided to open a fifth -- it's starting to become troll-like behavior, as you refuse to take "no" for an answer, and have decided to keep whining and screaming and effectively throwing a tantrum (see: when you refused to see me as anything but an OpenAPI representative because I had the audacity to comment on your issue).

I'd also like to suggest that if you're going to bring lawyers into the mix (even if a lawsuit isn't involved), that you keep that sort of thing in private. Your email and Darrel's email are both publicly viewable on your GitHub profiles, so use those if you need to talk lawyers (although so far, I can't truthfully feel like you have a grasp on how lawyers and the legal system actually work). Aside from that, GitHub issues is not the place to be talking legal issues anyways.

---

To any OAI members with management permissions, I really think you should lock this issue and block orubel from the OAI repositories permanently should this behavior continue, as this has gone on far too long. It's become troll-like behavior, as they refuse to take "no" for an answer -- and it's honestly surprising me that orubel hasn't been blocked already given what I've seen on other issues by orubel.

[orubel]

@LikeLakers2 No one has said no. You yourself have stated that OpenApi is not for Api Gateways if I remember accurately from the past ticket. @darrelmiller stated that OpenApi is not about 'shared state' and isn't generated from the API Application and denied that the API application and the endpoints are the central version of truth .

Most of the answers I have seen are very very questionable at best and lack an understanding of distributed architectures and shared state. You claim my questions are ambiguous but for those dealing with distributed architectures (which are 90% of API installs these days), they understand these issues quite clearly.

And I don't understand why you keep talking about lawyers. @darrelmiller is just unfortunately 'threatened' by an open letter to the openapi community posted on Twitter that I sent to the team (as well as it being a politeness) after @webron posted very rude remarks online not only to me but several others as well.

As for misattribution of the quote, considering its one of the most often misattributed quotes, I don't feel too bad. But thank you for the correction. I edited so it has the appropriate attribution now.

See how easy that is?

[orubel]

@LikeLakers2 @darrelmiller This ticket was opened to talk about 'Role' association to content and we went off topic talking about:

• 'shared state' (which you stated OpenApi is not concerned with)
• OpenApi is generated from a design doc not the endpoints of the API server
• the central version of truth for a running api system is NOT the api server endpoint according to you; it is a static design doc.

So if this is all true, why is OpenApi even pushing for use with Api Gateways??? Why does it have this documentation on its system? It sounds like you are creating a static design doc... not a shared state.

This is contrary to a document that needs to be used in a distributed architecture... especially on api gateways.

[philsturgeon]

1. you're talking about lawyers, that's threatening.
2. repeating "since 2017" over and over again doesn't make it any more true, you've been equally wrong for a long time
3. the video you're linking to as supporting your claims of OpenAPI having a security issues does not talk about this topic.
4. you dont seem to understand anything about the design-first workflow, which is a popular alternative to the code-first / annotations approach you always talk about: https://apisyouwonthate.com/blog/api-design-first-vs-code-first/
5. OpenAPI is YAML/JSON file which describes stuff an API can do so there's literally no security concerns there. If they dont have permissions they cant do the thing.
6. wtf is "shared state" anyway, and dont just keep shouting "distributed systems" yes we all write distributed systems.

I don't really need or want answers to this I'm just highlighting why people are tired of talking to you about this over and over again for years.

[philsturgeon]

Yes, great, it's a static design document, there is no shared state, no need for ROLES, and we're done here.

[orubel]

1. you're talking about lawyers, that's threatening.

Show me where.

2. repeating "since 2017" over and over again doesn't make it any more true, you've been equally wrong for a long time

Saying someone is wrong and PROVING someone is wrong are two different things. I learned this long ago when I found that the communication logic and the business logic were bound in the 1970's api pattern creating an architectural cross cutting concern when using said pattern in distributed architectures thus making the 1970's api pattern a single-tier pattern. I confirmed this numerous times when being invited to speak and consult with Mashery, Mulesoft, Vmware and others.

So merely saying someone is wrong has no weight in an argument. If you cannot PROVE that someone is incorrect in a technical discussion, what you are effectively doing is throwing a tantrum for lack of understanding yourself.

3. the video you're linking to as supporting your claims of OpenAPI having a security issues does not talk about this topic.

You think it doesn't because you fail to see how at the API Gateway

to repeat what is posted in the beginning of this ticket, If you read how people are using OpenApi in API Gateway, it is being used for ROUTING TO ENDPOINT POST CHECKING OF SECURITY.

Meaning :

• Security has been checked
• Token has been issue
• Api Gateway now uses OpenAPI to route to endpoint
• Gateway does a check for request and response data for endpoint using OPENAPI, REGARDLESS OF WHETHER:
  • USER has multiple ROLES
  • Endpoints expect different REQUEST/RESPONSE 'content' per ROLE

OPENAPI assumes an 'anonymous' ROLE (which is issued if no token is found on most systems) and as a result, assumes everyone has this ROLE by default when ROUTING.

This may not be the case when doing the PROCESSING but if it has no way to tell the system that different ROLES should send different request data when ROUTING, it just tells it one thing for everyone.

So it will always send to little/too much info and return too little/too much info (most likely too much info) which is in violation of API3:2019 Excessive Data Exposure

I'm trying my best to baby step you through this because I understand this is hard for you to understand, so please be patient.

4. you dont seem to understand anything about the design-first workflow, which is a popular alternative to the code-first / annotations approach you always talk about: https://apisyouwonthate.com/blog/api-design-first-vs-code-first/

I understand design first but in a WORKING API SYSTEM, NO ONE cares about syncronizing design docs. They care about syncronizing all the services in their architecture that share the request/response. And that's what documents like RAML, API BLUEPRINT and OPENAPI are supposed to do.

5. OpenAPI is YAML/JSON file which describes stuff an API can do so there's literally no security concerns there. If they dont have permissions they cant do the thing.

There are if it is used for routing. Routing is where you check access to that endpoint and what data to send/return. What data to send/return is based on ROLE.

6. wtf is "shared state" anyway, and dont just keep shouting "distributed systems" yes we all write distributed systems.

All the data about your endpoints needs to be shared with the other services in your architecture that share the request/response (ie the api call flow). That state they share for the api call flow is 'shared state'. They all need to have the EXACT SAME STATE for all endpoints so as to not get out of sync. OTHERWISE... when routing the call from one service to another, the 'state' one service uses to describe the 'api call flow will not match the other and you will

• route the call badly
• end up getting the call rejected
• send too much/too little information
• or worse, route a call allowing access that you shouldn't have.

The state from one service to the next to the next in the api call flow should all match the central version of truth (i.e. where the request/response meet) so that you can have a shared state that synchronizes and can be cached.

To see what 'shared state' can do, watch this: https://youtu.be/A_Hozpb9gLc

I don't really need or wnt answers to this

Obviously you do. You should know what shared state is if you are contributing to a project of this nature.

[orubel]

Yes, great, it's a static design document, there is no shared state, no need for ROLES, and we're done here.

sigh I'm trying to be serious and you're trying to be argumentative.

If you want to answer me seriously and have a technical discuss, I'm up for it but lets try not to demean each other by being so childish.

Are you being serious and is this a REAL answer from the OpenAPI Initiative?

[darrelmiller]

I'm serious: "it's a static design document, there is no shared state, no need for ROLES, and we're done here."