Ensure that security capability supports identity management for creating private resources

[ghobona]

The 2020-07 Sprint encountered a need for an ability to use identity management for creating private resources such that the server would be able to enable users to manage their own collections, styles or other resources.

The sprint participants felt that this was a Common issue.

[ghobona]

Please note that it is NOT related to the approach described at opengeospatial/ogcapi-maps#42 (comment)

[jerstlouis]

To clarify, it is related, but the deferred mode suggestion in opengeospatial/ogcapi-maps#42 is for temporary resources which supports scenarios where:

• no identify management is available, or
• wanting to make resources intrinsically transient, until a user explicitly want to convert them to a persistent resource

[ghobona]

The September 2020 Code Sprint demonstrated that OGC API - Common and OGC API - Features support the security mechanisms provided by the OpenAPI.

In my opinion, that is a sufficient level of identity management to support in OGC API - Common - Part 1: Core. If you agree with my opinion, then I propose that this issue is closed.

[bradh]

Use of OpenAPI isn't required by OGC API clients - there is an alternative HATEOAS (aka follow-the-links) approach. What is the security concept? Maybe something needed for the user guide?

[jerstlouis]

@bradh @ghobona
As far as I understand, the OpenAPI definition itself is not what provides the security capabilities, but merely allows to describe and examplify the use of e.g. OpenID Connect / OAuth2 access tokens (e.g. in its "Try it out" example usage of the API).
There is no mention of OpenAPI on the security diagram here:
https://github.com/opengeospatial/OGC-API-Sprint-September-2020/blob/master/Presentations/Security%20Architecture.pdf
However OpenAPI does identify these mechanisms as "standardized" security schemes as discussed here.

@ghobona I suggest we rephrase this as something like:

The September 2020 Code Sprint demonstrated that OGC API - Common and OGC API - Features can be used in conjunction with security mechanisms provided by the OAuth2 Authorization Framework (RFC 6749), OAuth2 Bearer Tokens (RFC 6750) OAuth2 Token Introspection (RFC 7662), and OpenID Connect, which are also identified as standardized security schemes for OpenAPI definitions.

@securedimensions @pomakis @joanma747 might want to correct or clarify this.

However I don't think OGC API - Common - Part 1: Core says much about this at all -- mainly the current security section only has one requirement that its OpenAPI definition should define the supported security scheme. It would likely be useful to have a dedicated Common part on security / identify management, and/or conformance classes indicating that some security scheme is supported by an implementation, to be declared in /conformance which would be available to clients without relying on parsing an OpenAPI definition (recognizing that Common - Part 1 requires an API definition, but that could be described using something else than OpenAPI).

A best practice document or a section in the user guide could also describe these standard and interoperable identify management mechanisms that OGC API implementations should/could provide, and provide guidance on how to implement them in practice.

[ghobona]

I'm happy with the rephrasing suggested by @jerstlouis

I also like the idea for a Best Practice to address identity management.

[securedimensions]

Jerome, all, Good discussion summary! The fact that OpenAPI defines “standard” security schemes and therefore allows to “mark” an endpoint of your API to require such a security scheme is not providing full interoperability with no hick-ups… There also needs to be a “protocol” that allows the client to DISCOVER the remaining “stuff”. For example, the fact that an API endpoint is marked as RFC 6750 (OAuth2 Bearer Token) does not help the client (developer) much unless knowing where to get the access_token form? OpenID Connect defines a standard discovery mechanism for the endpoints of an OP: ./well-known/openid-configuration (example: https://www.authenix.eu/.well-known/openid-configuration). But to my understanding, this can’t be included into the OpenAPI based description of your API. So, essentially the OGC API Common protocol must cover this, yes / no? So – to me – the challenge to API Common would be to ensure that the developer gets the required information to integrate the Bearer Token from the RIGHT OP. And, how would a client at runtime understand that only Bearer Tokens from – e.g. AUTHENIX – are accepted at this OGC API endpoint. So, don’t send a Google or Facebook token – that won’t work 😉 What about using WebFinger as a standard discovery mechanism as part of OGC API Common? Perhaps, a solution to ensure interoperability would be to define ?two? Conformance Classes in API Common that define how the required info is made available (using WebFinger)? Hope you see where I am going… Cheers Andreas From: Jerome St-Louis <notifications@github.com> Reply to: opengeospatial/ogcapi-common <reply@reply.github.com> Date: Saturday, 23. January 2021 at 01:27 To: opengeospatial/ogcapi-common <ogcapi-common@noreply.github.com> Cc: securedimensions <am@secure-dimensions.de>, Mention <mention@noreply.github.com> Subject: Re: [opengeospatial/ogcapi-common] Ensure that security capability supports identity management for creating private resources (#159) @bradh @ghobona As far as I understand, the OpenAPI definition itself is not what propvides the security capabilities, but merely allows to describe and examplify the use of e.g. OpenID Connect / OAuth2 access tokens (e.g. in its "Try it out" example usage of the API). There is no mention of OpenAPI on the security diagram here: https://github.com/opengeospatial/OGC-API-Sprint-September-2020/blob/master/Presentations/Security%20Architecture.pdf However it does identify "standard" security schemes as discussed here. @ghobona I suggest we rephrase this as something like: The September 2020 Code Sprint demonstrated that OGC API - Common and OGC API - Features can be used in conjunction with security mechanisms provided by the OAuth2 Authorization Framework (RFC 6749), OAuth2 Bearer Tokens (RFC 6750) OAuth2 Token Introspection (RFC 7662), and OpenID Connect, which are also identified as standardized security schemes for OpenAPI definitions. @securedimensions @pomakis @joanma747 might want to correct or clarify this. However I don't think OGC API - Common - Part 1; Core says much about this at all, and it would likely be useful to have a dedicated part, or conformance classes indicating that this is supported by an implementation, or at least a best practice document or a section in the user guide to describe this standard and interoperable identify management mechanism that OGC API implementations should provide. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.