Ciprian, This has gotten me closer, as my REST implementation is now able to see the Principal in requestContext.getSecurityContext().getUserPrincipal() in filters.
The Principal in REST API remains null. An example REST API is listCustomer(@Context HttpServletRequest servletRequest) and servletRequest.getUserPrincipal() return null. I created an authorization filter that: - validates the user credentials and creates customUserPrincipal with the username and roles - Creates a customerSecurityContext passing in the customUserPrincipal, or null if no authorization header existed. - Set the security context of the requestContext to the newly created customerSecurityContext. I also created an authentication filter that uses the security context from the requestContext and verifier the roles, as declared via javax.annotation.security, using the same logic as described in "Jersey REST API Security Example". Paul Spencer > On Jan 29, 2024, at 12:00 PM, Ciprian Ciubotariu <[email protected]> wrote: > > 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 <[email protected]> wrote: >>> >>> Steinar, >>> This helps! >>> >>> Paul Spencer >>> >>> On 2024/01/24 12:38:27 Steinar Bang wrote: >>>>>>>>> Paul Spencer <[email protected]>: >>>> >>>>> 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) >>>> >>>> >> >> > > > >
