AEP 4: Implicit permissions system for Apiman (discoverability)

[msavy]

Discoverability

Apiman's existing explicit permissions system provides fine-grained permissions for users who are a member of a given organisation.

Discoverability is an implicit read permissions system that layers on top of the explicit permissions systems that already exist in Apiman. It allows API Editors to expose APIs to consumers who are not members of their organisation.

There are a few extra bells and whistles in the discoverability system which allows the segregation of different categories of 'non-member' (as outlined below).

This is also a mechanism by which APIs can explicitly be exposed into the developer portal for anonymous users to browse (although they need an account to subscribe).

Acceptance criteria

• Can selectively expose an API outside of an organisation to non-members

• API Plans (i.e. Api Version + Plan Version) can have a discoverability.

• Public API Versions can have a discoverability.

• Can choose different levels of discoverability (i.e. who can find a given API):

  • Default: only members of the organization (existing explicit permissions system).
  • Only 'full' Apiman platform users with apiuser role.
  • Expose into the developer portal for anonymous access, and for signed-in developer portal users (and all above).

• Can distinguish between different categories of non-member via IDM roles; namely developer portal users (devportaluser) and 'full' Apiman platform users (apiuser).

  • i.e. the discoverability levels for a given role should be customisable; different categories of user may see different things.

• Can explicitly expose an API into the developer portal.

• No endpoints, including search, should return items a user (anonymous or logged-in) does not have permission to see.

  • i.e. All endpoints methods must fully implement discoverability.

• Backwards compatible as far as possible.

[msavy]

This is now completed and will form part of Apiman 3.0.0.Final

[amble42]

If you switch on Make API Public and publish the API , there doesn't seem to be a way to back out of that. If you then retire the API you are left with an API on the Marketplace which is there for ever.
Would be good to be able to expire the disability of an API in public state after a period of exposure in a retired state after a period of time.

[msavy]

If you switch on Make API Public and publish the API , there doesn't seem to be a way to back out of that

I think that might just be a UI limitation, but I'll have to verify it. As you guys are customers, I am happy to do that for you all in the supported version of Apiman 3.x.

I'll create a ticket for this soon.

If you then retire the API you are left with an API on the Marketplace which is there for ever.

I'm thinking that is arguably bug and we shouldn't show retired APIs. I can't think of a good reason to show retired APIs in the developer portal marketplace. Happy to fix that for you in supported Apiman 3.x.

I'll create a ticket for this soon.

Would be good to be able to expire the disability of an API in public state after a period of exposure in a retired state after a period of time.

Interesting idea, but I wonder whether we should just not show retired APIs at all in the devportal? We could add something like this to Apiman 4.x for you guys.