Hi Matt,
Well for me I don't actually call Subject.doAs in my CXF interceptor
(which calls myService.myMethod that was DS injected), rather, I have a
SecurityUtilities.runAs which checks for callAs and if not falls back to
doAs. Same with current subject. Perhaps an approach like this might
make sense to keep all the existing JAAS stuff in place.
It does something like this:
static {
Method callAsMethod = null;
Method currentMethod = null;
try {
// Subject.callAs(Subject, PrivilegedAction)
callAsMethod = Subject.class.getMethod("callAs", Subject.class,
PrivilegedAction.class);
} catch (final NoSuchMethodException ignored) {
// Subject.callAs(...) not available
}
try {
// Subject.current()
currentMethod = Subject.class.getMethod("current");
} catch (final NoSuchMethodException ignored) {
// Subject.current() not available
}
CALL_AS_METHOD = Optional.ofNullable(callAsMethod);
CURRENT_METHOD = Optional.ofNullable(currentMethod);
}
The reason I wanted to use Service Guard is the platform enforced it
with a common way for ACLs similar to command/jmx ACLs. I would prefer
not having to do these checks myself in all methods or doing my own
proxy service.
On Tue, Jun 10, 2025 at 12:05:26PM -0500, Matt Pavlovich 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
> >>
> >
>
