[
https://issues.apache.org/jira/browse/JSPWIKI-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1315:
-----------------------------------
Description:
Scope changed after the discussion on [email protected]: enterprise
authentication such as OpenID Connect should be left to the servlet container
and the directory behind it, and JSPWiki should not reimplement it. The
original proposal of a login module inside JSPWiki is withdrawn. It would only
be reconsidered if the container turns out not to be enough.
What exists today: JSPWiki supports container managed authentication through
WebContainerLoginModule in org.apache.wiki.auth.login, and the roles come from
the container. The closed issue JSPWIKI-1176 describes this set up with JBoss
EAP and roles from Active Directory, where the reporter needed a role mapper in
the container to map the directory roles to the roles Admin and Authenticated
that JSPWiki expects.
Proposal: set up OpenID Connect in a container (for example WildFly with
Keycloak as the provider, and one other container) and check that login, the
roles, the permission checks in jspwiki.policy, logout and session expiry work
with JSPWiki. Write the results down in the administrator documentation, with
the web.xml and role mapping needed for each container that was tested. Fix
what does not work, and open separate issues for the individual problems. It is
not known yet whether anything fails, so this issue may end up being
documentation only.
Related issues: JSPWIKI-1176 (closed), JSPWIKI-861 and JSPWIKI-94 (older
requests for OAuth and OpenID).
was:
This is a proposal for discussion, not an implementation. Organisations that
run a wiki expect to sign in with the identity provider they already have, such
as Keycloak, Azure AD or Google Workspace, and today JSPWiki cannot do that
without container specific setup.
What exists today: authentication is JAAS based. The modules in
org.apache.wiki.auth.login are UserDatabaseLoginModule (the default, selected
with jspwiki.loginModule.class), WebContainerLoginModule (container managed
authentication), CookieAuthenticationLoginModule and
CookieAssertionLoginModule, and AnonymousLoginModule. Single sign-on therefore
depends on what the servlet container offers. The open issues JSPWIKI-861
(OAuth, Facebook) and JSPWIKI-94 (OpenID) ask for something related but are old
and narrower.
Proposal: add an optional login module, or a small authentication filter, that
implements the OpenID Connect authorization code flow with PKCE against a
configured issuer (discovery document), maps claims to the wiki login name,
full name, e-mail and roles or groups, and works next to the existing modules
so that nothing changes for installations that do not configure it. Open
questions: whether the dependency on an OIDC library is acceptable (a well
maintained one with an Apache compatible licence would be needed), how provider
groups map to JSPWiki groups and to the roles Admin and Authenticated (see
JSPWIKI-1176), and how logout and session expiry should behave.
Related issues: JSPWIKI-861, JSPWIKI-94, JSPWIKI-1176. Direction to be
discussed on [[email protected]|mailto:[email protected]] first.
Summary: Verify and document OpenID Connect single sign-on through the
servlet container (was: Support OpenID Connect login for single sign-on with
an external identity provider)
> Verify and document OpenID Connect single sign-on through the servlet
> container
> -------------------------------------------------------------------------------
>
> Key: JSPWIKI-1315
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1315
> Project: JSPWiki
> Issue Type: New Feature
> Reporter: Arturo Bernal
> Priority: Major
>
> Scope changed after the discussion on [email protected]: enterprise
> authentication such as OpenID Connect should be left to the servlet container
> and the directory behind it, and JSPWiki should not reimplement it. The
> original proposal of a login module inside JSPWiki is withdrawn. It would
> only be reconsidered if the container turns out not to be enough.
>
> What exists today: JSPWiki supports container managed authentication through
> WebContainerLoginModule in org.apache.wiki.auth.login, and the roles come
> from the container. The closed issue JSPWIKI-1176 describes this set up with
> JBoss EAP and roles from Active Directory, where the reporter needed a role
> mapper in the container to map the directory roles to the roles Admin and
> Authenticated that JSPWiki expects.
>
> Proposal: set up OpenID Connect in a container (for example WildFly with
> Keycloak as the provider, and one other container) and check that login, the
> roles, the permission checks in jspwiki.policy, logout and session expiry
> work with JSPWiki. Write the results down in the administrator documentation,
> with the web.xml and role mapping needed for each container that was tested.
> Fix what does not work, and open separate issues for the individual problems.
> It is not known yet whether anything fails, so this issue may end up being
> documentation only.
>
> Related issues: JSPWIKI-1176 (closed), JSPWIKI-861 and JSPWIKI-94 (older
> requests for OAuth and OpenID).
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
