[jboss-jira] [JBoss JIRA] (WFCORE-3658) Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario

Security context propagation using Elytron API doesn't work for EJB to protected Servlet scenario ------------------------------------------------------------------------------------------------- Key: WFCORE-3658 URL: https://issues.jboss.org/browse/WFCORE-3658 Project: WildFly Core Issue Type: Enhancement Components: Security Reporter: Ondrej Lukas Assignee: Jan Kalina Priority: Critical One of the scenarios which are expected to work in Elytron is a Security context propagation from a protected EJB to a protected Servlet using HttpUrlConnection (details in RFE EAP7-284). The scenario doesn't work for me. My configuration: {noformat} EJB client -> protected EJB on server-1 -> protected Servlet on server-2 (BASIC authn) {noformat} The EJB contains following code: {code:java} final Callable<String> callable = () -> { URLConnection conn = url.openConnection(); conn.connect(); try (InputStream is = conn.getInputStream()) { return IOUtils.toString(is, StandardCharsets.UTF_8); } }; AuthenticationContext.empty().with(MatchRule.ALL, AuthenticationConfiguration.empty() .useForwardedIdentity(SecurityDomain.getCurrent()) .setSaslMechanismSelector(SaslMechanismSelector.ALL)) .runCallable(callable); {code} The server-2 returns 401: {noformat} java.io.IOException: Server returned HTTP response code: 401 for URL: http://127.0.0.1:8180/seccontext-server2/whoAmI at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1876) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474) at org.wildfly.test.manual.elytron.seccontext.EntryBean.lambda$readUrl$1(EntryBean.java:69) {noformat} There is still a chance, the problem is in the scenario configuration, but the documentation is silent about this topic. The problem could be in a missing integration of ElytronAuthenticator within the AuthenticationContext. I don't see it used when I debug the scenario. When I register the authenticator manually, I see another problem which will be reported in a separate JIRA.