I am converting over a part of an application from using the authc
filter to a bearer token filter for the API and I have things working
well enough, but one place I have an issue. I expose an openapi-ui in
my application and if I'm authenticated to the "web" side with the authc
filter and attempt to use the openapi-ui (basically swagger-ui) to test
an API call it fails with unauthorized even though the bearer token is
being authenticated because as far as I can tell it's pulling my "web"
principal out of the ThreadContext and authorizing with that. The API
keys are associated with a user in my data model but each have their own
permissions as selected at creation time. The principal for an API key
(which is purely permission based) is different from the principal for
the authc filter (which is just RBAC at this point).
If I'm already logged into the application then one of the first things
that happens when I attempt to make a request using the openapi-ui is:
06:57:07,762 TRACE [org.apache.shiro.util.ThreadContext] (default
task-22) Bound value of type
[org.apache.shiro.web.subject.support.WebDelegatingSubject] for key
[org.apache.shiro.util.ThreadContext_SUBJECT_KEY] to thread [default
task-22]
and then much later at the bottom I can see it logging my web principal
(showing my username).
but if I just use curl early on I see:
07:02:53,626 TRACE [org.apache.shiro.mgt.DefaultSecurityManager]
(default task-22) No identity (PrincipalCollection) found in the
context. Looking for a remembered identity.
and then it flows completely through the bearer process and it works
fine because it's using THAT principal and getting the proper permissions.
Is there a way to prevent this from happening? I think it's just the
fact that the browser is "logged in" and since it's going through the
request to those pages it loads up the web user first and binds it and
then the bearer token is ignored and permissions lookup doesn't work.
Thanks,
Dave
