[
https://issues.apache.org/jira/browse/ISIS-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17645605#comment-17645605
]
Daniel Keir Haywood edited comment on ISIS-3305 at 12/10/22 12:58 PM:
----------------------------------------------------------------------
In general, I like the idea of reducing proprietary stuff, and I like the idea
that any login pages/logout would be reusable across all viewers.
However, for Estatio we have been doing some work in this space, integrating
Causeway v2 with an external OAuth provider (Azure AD/Office 365), whereby that
external provider handles the login pages completely (same as Keycloak would).
For the Wicket viewer, I don't think we had to make any changes to Causeway,
but for Restful Objects it _will_ be necessary to make some small changes, to
be tackled in Jan 2023... i expect one or two small PRs for that. So it
might make sense to let that work come in first.
Regarding dropping SudoService etc, I would rather not, as that impacts
integration testing code. These days it's just syntax sugar on top of the
InteractionService. Should InteractionService itself be refactored to
integrate with Spring's SecurityContextHolder etc? Maybe, but only if it
continues to expose the same API for integration testing.
Should we change impersonation? What I like about our current implementation
is that it isn't necessary to logout and login with a different user, the
effective user can be changed. We use this feature a lot for Estatio, eg in
doing demos and debugging issues. Requiring a logout would be a retrograde
step.
Below, in more detail:
re: (1) drop Shiro support
Yes, I would be ok about this
re: (2) drop Keycloak support ...
My recollection is that our Keycloak support is not much more than configuring
Spring security's Oauth support. but looking at our code I see we have just a
couple of classes there, that are mostly to handle the logout oauth flow.
So, yes, I could see that this module could perhaps be removed, with the logout
stuff instead becoming generic and usable across all viewers. All that would
remain of the keycloak module itself would be some docs/screenshots on how to
set up Causeway for OAuth against Causeway.
re: (3) fully integrate with Spring Security
Yes, this makes sense, but let's wait until the PRs due in Jan 2023 arrive
re: (4) drop SudoService
No, SudoService is useful syntactical sugar over InteractionService, we use
both in integration tests and also use InteractionService in quartz background
cron jobs. I would suggest that their APIs need to be preserved, but their
implementation could indeed change to work with Spring Security in the various
contexts.
For the record, the various contexts I see are:
* a server-side auth flow for HTML viewers such as Wicket (where there's a
redirect to the login pages of the OAuth provider etc)
* a client-side auth flow for Rest APIs ... this is the PR for Jan 2023.
* integration testing, where we programmatically create a session with
arbitrary user/roles.
* Quartz cron jobs, where we again programmatically create a session with
arbitrary user/roles
re: (5) impersonation via a login page
Not keen on this, feels retrograde from what we support at the moment
re: (6) drop Wicket's /login, /logout, & (7) replace with Spring /security/
Think this is ok, to instead become generic support for all viewers.
However, we do today have support for custom registration pages etc, so I would
want to make sure that the equivalent capabilities were still supported through
OAuth (I suspect they are). Or, at a very minimum, survey current users to see
if these features can be removed.
was (Author: danhaywood):
re: (1) for dropping Keycloak support ...
I don't think we want to do this, because actually our Keycloak support is
really nothing more than docs on how to configure Spring security's Oauth
support.
> [DISCUSS] Re-platform on top of Spring security.
> ------------------------------------------------
>
> Key: ISIS-3305
> URL: https://issues.apache.org/jira/browse/ISIS-3305
> Project: Isis
> Issue Type: Improvement
> Affects Versions: 2.0.0-M9
> Reporter: Daniel Keir Haywood
> Priority: Major
> Fix For: 2.1.0
>
>
> as per [https://the-asf.slack.com/archives/CFC42LWBV/p1670661588201299]
>
> Andi's wish list of changes is:
> # drop Shiro support
> # drop Keycloak support
> # instead fully integrate with Spring Security
> # drop SudoService
> # instead provide impersonation via a specialized login page
> # drop Wicket's .../login, .../logout
> # instead provide simple replacements under /security/... central to the
> application (not using Wicket)
> Why? Focus on one security stack and do that integration well
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
