Repository navigation
Conversation
Signed-off-by: Maximilian Oedinger <maximilian.oedinger@sva.de>
| 3. Invites are an optional concept that can be reconciled by a controller implementation if needed | ||
| - the default implementation would need to change the same way as when `Invite` is authentication only but a core concept | ||
| - invites may be omited when not required | ||
| - higher configuration complexity |
There was a problem hiding this comment.
This option was already discussed here #neonephos-platform-mesh-discussion > Invites feature in PM
I want to comment real quick, that i like Kevin's take on this, especially if i did understand it correctly, that reconciliation of the Invite is optional, which is the key decision driver in this case, as it is nice-to-have when u need it but does not disrupt adoption if invites is something i do not want/need.
| *This builds upon the assumption that tenant isolation work organization workspaces is the desired authentication model* | ||
| *adopters could also think about operating multiple workspaces with the same oidc idp which would require platform mesh to define its own identity segmentation model or rely on authorization alone to ensure unauthorized access to org-seperated-workspaces resources* |
There was a problem hiding this comment.
I want to refer to this comment by MJ as it rightfully pulls this topic into question when talking about modularizing authentication. Even though for example the proposed User-CRD within the organization-workspace could be used/extended to serve as som kind of user-to-workspace mapping this does make authentication a whole lot more complicated and I am not sure if this discussion is something we should have right know.
Platform Mesh is currently very clearly build upon the idea of isolation on the organization level. This isolation is defined by separate keycloak realms in the default configuration, which is what the platform mesh authors intend to be a valid solution to the idp isolation.
If an adopter requires the use of the same idp with the same users for multiple workspaces, thats a problem that the adopter needs to solve themselves imo.
The only question that could be discussed is, if Platform Mesh offers a tool out of the box in form of an API that can be implemented to solve this problem.
| This bundling requires a custom IAM-Service implementation including authorization even when just authentication is being replaced with a non-default solution. | ||
|
|
||
| 1. To consider the current implementation as a RFC 008 compliant boundary we must assume: | ||
| - the `ResolverService` interface is a satisfying api boundary thats independent from its implementation |
There was a problem hiding this comment.
I am currently especially sceptical about this assumption hence i did propose choosing option 2 in this case.
I'm afraid, that the goal stated about the IAM-Service:
Its design is prepared to allow for alternative implementations to support different Identity Providers.
may conflict with the definition of a replaceable interface/boundary as defined in RFC 008.
| ### Authentication-Protocol | ||
| The clear contender is OpenID Connect (OIDC) as it is the currently used protocol and one of the default authentication strategies supported by KCP. As already mentioned in RFC 008 DCR(RFC 7591 Dynamic Client Registration) should also be part of the extended open standard, as it ensures the necessary functionality that the reconcilitation of authentication configurations within platform mesh requires to be feasible. | ||
| Even though there are alternatives for the basic authentication functionality of OpenID Connect (for example SAML 2.0) none of them are worth considering over OIDC + DCR) | ||
|
|
There was a problem hiding this comment.
I think it would be helpfull to outline were other domains have dependencies on the authentication part:
- Primary user identifier in your authorization system - how do i configure it?
- Member screen - how would i implement a user suggestion?
- Multi tenancy - how is a user identifier prefixed? How does PM make sure each tenant has a unique identifier?
- What values are required in a JWT, especially when technical user access is also involved?
- Portal - what oidc flows are required to be supported by an authentication provider?
- MCP - CIMD could be a requirement too
Max-0e
changed the title
ADR 018 - Authentication Module Boundaries
This ADR addresses the Boundaries/API-Contract of the Authentication module/capability
Goals:
Align decisions and choices to define the boundary to the RFC 008 and make considerations where boundaries could be defined in different ways.
Outside the scope:
Define Boundaries for Authz or the UI Module/Capabilities