The way I have done it in the past is to set the security context with a custom
implementation on the authentication success path, such as:
requestContext.setSecurityContext(new
CustomSecurityContext(username));
and have a class implementing the security context, and another the user
principal.
public class CustomSecurityContext implements SecurityContext {
private CustomUserPrincipal principal;
CustomSecurityContext(String username) {
this.principal = new CustomUserPrincipal(username);
}
@Override
public Principal getUserPrincipal() {
return principal;
}
....
}
This could be extended with more data for authorization (roles etc), or perhaps
you can find a stock library that already suits your needs.
Ciprian
On Monday, 29 January 2024 18:43:40 EET Paul Spencer wrote:
> Steiner,
> Just a followup:
>
> - The Shiro 1.13.0 feature is missing required Shiro and Apache commons
> bundles, which may be resolved in 2.0 alpha, as well as the config package is
> split across multiple bundles, described in SHIRO-654 and also resolved in
> 2.0 alpha. So despite your examples, I was not able to get version 1.13.0
> working.
>
> - aries-jax-rs-whiteboard-shiro v2.0.2 feature installs, but I could not get
> the realm configuration working, as I was unable to find examples.
>
> - Jersey REST API Security Example,
> https://howtodoinjava.com/jersey/jersey-rest-security/, provided a way to
> utilize the javax.annotation.security annotations and
> authentication/authorization stored in a database. This implementation is
> simply a filter that does the authentication/authorization and updates the
> response with the appropiate success or fail code. It does not set the user
> principle in the session.
>
>
> At this point I am utilizing the "Jersey REST API Security Example" because:
> - JAXRS Service is utilizing standard security annotations.
> - My implementation is for internal use only and protected behind firewalls.
> - I am out of time.
>
>
> I will continue to look for a solution that leverage the OSGi JAX-RS
> whiteboard REST service and the security services within Karaf as time
> becomes available.
>
> Paul Spencer
>
>
>
> > On Jan 24, 2024, at 5:08 PM, Paul Spencer <pau...@apache.org> wrote:
> >
> > Steinar,
> > This helps!
> >
> > Paul Spencer
> >
> > On 2024/01/24 12:38:27 Steinar Bang wrote:
> >>>>>>> Paul Spencer <paulspen...@mindspring.com>:
> >>
> >>> Karaf 4.4.5
> >>> How do I protect a OSGi JAX-RS whiteboard REST service using Basic
> >>> Authentication?
> >>
> >> Apache Shiro can do basic auth (among other things).
> >> https://shiro.apache.org
> >>
> >> This project is a shiro realm with a simple JDBC database and a react.js
> >> frontend to to user management:
> >> https://github.com/steinarb/authservice
> >>
> >> You can install it directly in karaf by installing it's karaf feature
> >> (the feature and all bundles are released to maven central, and is
> >> released under APLv2).
> >>
> >> Some web whiteboard projects using authservice for users and roles and
> >> stuff:
> >> https://github.com/steinarb/oldalbum/blob/master/oldalbum.web.security/src/main/resources/shiro.ini
> >> https://github.com/steinarb/ukelonn/blob/master/ukelonn.web.security/src/main/resources/shiro.ini
> >> https://github.com/steinarb/handlelapp/blob/master/handlelapp.web.security/src/main/resources/shiro.ini
> >> https://github.com/steinarb/sampleapp/blob/master/sampleapp.web.security/src/main/resources/shiro.ini
> >>
> >> None of them use basic auth, but that should basically (pun not
> >> intended) just be to replace "authc" with "authcBasic".
> >>
> >> Later specific definitions in the [url] sections, will override earlier
> >> more generic definitions. So you can block the API requiring a loging
> >> of a user with a certain role, and then open up for e.g. login or login
> >> state check endpoints.
> >>
> >> (The reason for anon access of many rest endpoints is to avoid 302
> >> redirects on REST API calls I need to do before logging in, because web
> >> browsers don't handle 302 redirects on REST API calls real well)
> >>
> >>
>
>
