search

NASA-IMPACT / veda-auth-central

Standard based security solution tailored for VEDA comprehensive user authentication, centralized user profile management, and intelligent authorization decisions.
Apache License 2.0
4 stars 8 forks source link

VEDA Auth Central REST API Changes Required #57

Open lahirujayathilake opened 5 months ago

lahirujayathilake commented 5 months ago

This issue is to track and discuss the required modifications and additions to the VEDA Auth Central REST APIs.

### Tasks
### Tasks
- [ ] https://github.com/NASA-IMPACT/veda-auth-central/issues/57
- [ ] https://github.com/NASA-IMPACT/veda-auth-central/issues/56
lahirujayathilake commented 5 months ago

Two issues were created based on the Discussion with @alukach and @j08lue

  1. https://github.com/NASA-IMPACT/veda-auth-central/issues/57
  2. https://github.com/NASA-IMPACT/veda-auth-central/issues/56
alukach commented 5 months ago

Thanks @lahirujayathilake! Another detail:

Currently, the API spec demonstrates the /api/v1/identity-management/user endpoint:

image

I believe this is intended to be an implementation of the OIDC UserInfo endpoint (5.3). It seems that the industry has conformed to using /userinfo as the common endpoint for this purpose, but I think that's just convention. However, I do believe we're slightly out-of-spec:

  • Communication with the UserInfo Endpoint MUST utilize TLS. See Section 16.17 for more information on using TLS.

✅

  • The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST methods defined in RFC 7231 [RFC7231].

❌ I don't believe we are currently supporting the POST method

⚠️ We do support access tokens as per RFC6750, however we are providing them as query parameters which is the least desirable method of transport. Reading RFC6750, we can see:

Because of the security weaknesses associated with the URI method (see Section 5), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body. Resource servers MAY support this method.

I don't believe that there's any reason that we couldn't use an auth header to transport the token and I believe it would provide improved securit.

  • The UserInfo Endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) [CORS] and/or other methods as appropriate to enable JavaScript Clients and other Browser-Based Clients to access it.

❓ Not sure about CORS support at this point.