search

opengeospatial / ogcapi-common

OGC API - Common provides those elements shared by most or all of the OGC API standards to ensure consistency across the family.
https://ogcapi.ogc.org/common
Other
45 stars 14 forks source link

Ensure that security capability supports identity management for creating private resources #159

Open ghobona opened 4 years ago

ghobona commented 4 years ago

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 commented 4 years ago

Please note that it is NOT related to the approach described at https://github.com/opengeospatial/OGC-API-Maps/issues/42#issue-664941889

jerstlouis commented 4 years ago

To clarify, it is related, but the deferred mode suggestion in https://github.com/opengeospatial/OGC-API-Maps/issues/42 is for temporary resources which supports scenarios where:

ghobona commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

I'm happy with the rephrasing suggested by @jerstlouis

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

securedimensions commented 3 years ago

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.

m-mohr commented 1 week ago

What is the status of this?

There are various initiatives in OGC that have a need for standardized authentication mechanisms such as OSPD and GDC. Without further specifics the clients won't be able to interact with the servers in a user-friendly way.

While OpenAPI allows to provide some information, it seems insufficient (as stated also above) and it allows for too many options to choose from, making it hard to implement generic clients.

In openEO we defined two ways auf Authentication: Simple HTTP for development purposes and OpenID Connect for production. See https://api.openeo.org/#section/Authentication and https://api.openeo.org/#tag/Account-Management for details. It would be very valuable if something like this would be available in OGC APIs, too. In recent OGC initiatives I've participared in, it was OpenID Connect was usually the common ground that most people were happy with, as such I feel it's a good starting point/recommendation. We are happy to provide (and extend) the openEO API mechanism if OGC members want to adopt it. It is already adopted in federated environments, too, e.g. CDSE and openEO Platform. We've also used this mechanism in various projects, including TB19 across openEO and OGC APIs.

Anyway, I think it is time to come up with at least recommendations so that authentication will be streamlined and doesn't become an actual issue to projects (as seen in OSPD for example, and faced again in EOEPCA+). I see there's a Security DWG, and I'd assume it falls into their domain so would be happy to hear their thoughts and collaborate on this important topic. I guess eventually this could become a separate part in OGC API - Common.

gfenoy commented 1 week ago

As the OGC GDC profile includes the http-basic and openid-connect conformance classes, I volunteer to start a new part for the OGC API - Common, which would add these conformance classes to apply them at the root level of any OGC API.

This way, the GDC can rely on this new part of OGC API - Common rather than defining it at the GDC level. Also, any other OGC API requiring authentication would benefit from such conformance classes at the OGC API - Common level.

We can talk about this in the upcoming SWG meeting.

@securedimensions and @m-mohr would be more than welcome to attend this meeting.

Should we consider integrating WebFinger into the current OpenEO definition or if we can let this aside and start using what is available within OpenEO?

m-mohr commented 1 week ago

I have no experience with WebFinger yet so can't really judge it right now. I'm not available at the next Common meeting spots unfortunately. (Wed, 17:00 CEST, right?)

We could also start drafting it in GDC - e.g. converting openEO requirements to "OGC style" - and migrate it to Common later if that simplifies it. No preference.

jerstlouis commented 1 week ago

@m-mohr I think @gfenoy was talking about the next Processes meeting which is 9:00 AM Mondays every 2 weeks, I think it's not next week but following week.

The Common meeting is right after our GDC meeting, Thursdays 11:00 AM Eastern (might have one today)

gfenoy commented 1 week ago

@jerstlouis, I spoke about today's meeting. Nevertheless, we just postponed to next week this discussion to be handled during the GDC meeting.

Looking forward to next week OGC API - Common meeting!

m-mohr commented 1 week ago

Right, my fault, it's Thu 17:00 CEST. This week I'm not available, but happy to join next week.

fmigneault commented 1 week ago

Just my 2 cents, based on older comments and planned work on this issue, but make sure any Auth Conformance Class defined by OGC does not depend on OpenAPI, WebFinger, or any other "tools", to describe the authentication schemes needed by a server. A server definitely can describe them in OpenAPI, to make them usable through a Swagger interface and provide additional documentation, but this is not how a server must advertise such details.

Pure HTTP responses and OAuth2.0 provide everything needed (namely, directives like WWW-Authenticate, Proxy-Authenticate that MUST be returned when a resource is protected) to indicate to a client which Authentication scheme and where to use them applies for a given resource, regardless of Basic, Bearer, etc.

IMHO, there are too many Auth-Schemes to consider (see IANA link), and replicating individual schemes in OGC Commons with distinct Conformance Classes is unproductive and limiting implementations. Instead, there should be a single Conformance Class, that guides on how to discover the applicable schemes (using the methods described by the RFCs, not custom ones). Considerations about well-known links should also be mentioned and followed.