Remote EJB Identity Propagation with Bearer Token mechanism

281 views
Skip to first unread message

Andreas Kappler

unread,
Jan 9, 2023, 9:51:40 AM1/9/23
to WildFly
Hi,

I am trying to set up Identity Propagation with wildfly according to the JBoss documentation to propagate the security identity of a user over a remote EJB call.

We are using bearer tokens to authenticate users, so both forwarding and receiving server are configured with a elytron/token-realm. Since the BEARER_TOKEN mechanism is supported according to this list, and we are using the remote EJB over HTTP protocol, I would expect the forwarding server to set a "Authorization: Bearer xxx" header on the remote EJB http calls. However this header is not set, and the receiving server returns a HTTP 401.

Here is the configuration of the forwarding server:

/subsystem=ejb3/application-security-domain=other:write-attribute(name=security-domain,value=ApplicationDomain)

/subsystem=elytron/authentication-configuration=remote-ejb-configuration:add(security-domain=ApplicationDomain)
/subsystem=elytron/authentication-context=remote-ejb-context:add(match-rules=[{authentication-configuration=remote-ejb-configuration}])

/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-partner-ejb/:add(host="localhost",port="8080")
/subsystem=remoting/remote-outbound-connection=remote-ejb:add(outbound-socket-binding-ref=remote-partner-ejb, authentication-context=remote-ejb-context)


I get this error on the forwarding server side:

Caused by: javax.naming.AuthenticationException: WFHTTP000013: Authentication failed (full response ClientResponse{responseHeaders={Connection=[keep-alive], WWW-Authenticate=[Bearer realm="jwt-realm"], Set-Cookie=[JSESSIONID=xxx; path=/wildfly-services], Server=[nginx/1.23.3], Content-Type=[text/html], Content-Length=[77], Date=[Mon, 09 Jan 2023 10:34:00 GMT]}, responseCode=401, status='Unauthorized', protocol=HTTP/1.1})


There is also a quickstart showing this scenario, but it uses the proprietary remote EJB protocol along with SASL, instead of HTTP. I could not find any examples showing this use case, so I am wondering if this is even supported.

Has anyone had any luck setting up something similar to this?

Best,
Andreas
Reply all
Reply to author
Forward
0 new messages