One other issue with simply ‘cutting over’ to use current()/callAs() methods is that it will break existing applications that use the previous JAAS API (that is now deprecated).
I suspect we need a big config switch somewhere in etc/org.apache.karaf.jaas.cfg (or a system property) that defines the behavior and allows users to ’switch back’ if they need to. Matt Pavlovich > On Jun 10, 2025, at 12:05 PM, Matt Pavlovich <mattr...@apache.org> wrote: > > This thread got me digging deeper and current() and callAs(), and I confirmed > that they use Thread scopedValues, so those are Virtual Thread “ready” vs > using Thread Local. > > I’m still not sure what value they provide to the coder over the alternative > of simply looking up the current Subject from session? > > There is also this line is in the JDK 21 Javadoc for > javax.security.auth.Subject for both current() and callAs() > > "This behavior is subject to change in a future version." > > Thanks, > Matt Pavlovich > >> On Jun 10, 2025, at 11:03 AM, apache-karaf-...@pyr3x.com.invalid >> <apache-karaf-...@pyr3x.com.INVALID> wrote: >> >> Hi Matt, >> >> Why not use Subject.current and Subject.callAs? >> >> On Tue, Jun 10, 2025 at 10:20:06AM -0500, Matt Pavlovich wrote: >>> Hi Chaz- >>> >>> I started making updates to be able to better support working with extended >>> and custom Principals. >>> >>> ref: https://github.com/apache/karaf/pull/1946 >>> ref: https://github.com/apache/karaf/pull/1944 >>> >>> NOTE: there is no planned JDK replacement for many of the JAAS operations >>> that you described. >>> >>> The recommended approach is to build in your own guard around operations >>> that you to secure with roles. >>> >>> -Matt Pavlovich >>> >>>> On Jun 10, 2025, at 10:08 AM, apache-karaf-...@pyr3x.com.invalid >>>> <apache-karaf-...@pyr3x.com.INVALID> wrote: >>>> >>>> On Tue, Jun 10, 2025 at 10:47:34AM -0400, apache-karaf-...@pyr3x.com wrote: >>>>> Hello, >>>>> >>>>> I'm using Karaf Service Guard to centralize authc/authz between karaf >>>>> commands and my REST interface. Everything is working an expected, >>>>> however, using a role with a colon in it is not matching. >>>>> >>>>> On the REST side I use Apache Shiro and I have realms that authenticate >>>>> to some backend systems who set roles like "group:blah". I convert these >>>>> to Karaf JAAS RolePrincipal which works for simple names like "blah". >>>>> I have a CXF Interceptor to execute REST methods inside a Subject.doAs >>>>> for my DS injected service. However, in the service acl when I have >>>>> something like this it fails: >>>>> >>>>> service.guard = (objectClass=com.example.MyInterface) >>>>> >>>>> * = * >>>>> myMethod = admin, viewer, group:blah >>>>> >>>>> -- >>>>> Chaz >>>> >>>> Update: >>>> >>>> Looking at the code for: >>>> >>>> https://github.com/apache/karaf/blob/main/util/src/main/java/org/apache/karaf/util/jaas/JaasHelper.java >>>> >>>> It looks at the first colon to separate a custom role principal name. >>>> >>>> This hack seems to work: >>>> >>>> org.apache.karaf.jaas.boot.principal.RolePrincipal:group:blah >>>> >>>> When reviewing the code I realized there are likely to be some issues in >>>> Java 21, specifically the replacement of Subject.doAs with callAs, and >>>> the new Subject.current(). >>>> >>>> Is this on the roadmap? Also, any thoughts on what to do with >>>> Conditional Permission Admin past Java 17? In my module system I like to >>>> lock down bundles to where they are allowed to write on the filesystem >>>> for example. >>>> >>>> -- >>>> Chaz >>> >> >
