[JBoss JIRA] (WFCORE-3175) The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3175?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3175:
---------------------------------------
I've changed this to a blocker because the patch makes it look like the bug is actually in the {{InstallationManagerService}}.
> The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
> ------------------------------------------------------------------------------
>
> Key: WFCORE-3175
> URL: https://issues.jboss.org/browse/WFCORE-3175
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching , Test Suite
> Reporter: James Perkins
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Fix For: 3.0.0.CR1
>
>
> The {{BootLoggingPatchingStateTestCase}} tests two patches which use a different version and product id for the patch. The tests currently pass because of the order of the [{{Collection.containsAll()}}|https://github.com/wildfly/wildfly-core/blob/0b51f7c1cce7286bf4f4e3f5c9250bf351bbdf1b/testsuite/patching/src/test/java/org/jboss/as/test/patching/BootLoggingPatchingStateTestCase.java#L151]. However if this is flipped the tests fail.
> It appears that the messages logged always contain the "WildFly" product id. Also the UUID for the failing examples seems to not be logged either.
> Example of logged messages for the "lp1" patch in the test:
> {code}
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> It looks like the same message is logged twice. However the following is what's expected:
> {code}
> lp1 cumulative patch ID is: base, one-off patches include: 50a820e4-3659-437d-86f2-fa1d64728adb
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> I'm not sure if this is just an issue with the test or if there is a bug in patching.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3175) The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3175?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3175:
----------------------------------
Fix Version/s: 3.0.0.CR1
> The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
> ------------------------------------------------------------------------------
>
> Key: WFCORE-3175
> URL: https://issues.jboss.org/browse/WFCORE-3175
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching , Test Suite
> Reporter: James Perkins
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Fix For: 3.0.0.CR1
>
>
> The {{BootLoggingPatchingStateTestCase}} tests two patches which use a different version and product id for the patch. The tests currently pass because of the order of the [{{Collection.containsAll()}}|https://github.com/wildfly/wildfly-core/blob/0b51f7c1cce7286bf4f4e3f5c9250bf351bbdf1b/testsuite/patching/src/test/java/org/jboss/as/test/patching/BootLoggingPatchingStateTestCase.java#L151]. However if this is flipped the tests fail.
> It appears that the messages logged always contain the "WildFly" product id. Also the UUID for the failing examples seems to not be logged either.
> Example of logged messages for the "lp1" patch in the test:
> {code}
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> It looks like the same message is logged twice. However the following is what's expected:
> {code}
> lp1 cumulative patch ID is: base, one-off patches include: 50a820e4-3659-437d-86f2-fa1d64728adb
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> I'm not sure if this is just an issue with the test or if there is a bug in patching.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3175) The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3175?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3175:
----------------------------------
Priority: Blocker (was: Major)
> The BootLoggingPatchingStateTestCase fails if the message assertion is flipped
> ------------------------------------------------------------------------------
>
> Key: WFCORE-3175
> URL: https://issues.jboss.org/browse/WFCORE-3175
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching , Test Suite
> Reporter: James Perkins
> Assignee: Alexey Loubyansky
> Priority: Blocker
> Fix For: 3.0.0.CR1
>
>
> The {{BootLoggingPatchingStateTestCase}} tests two patches which use a different version and product id for the patch. The tests currently pass because of the order of the [{{Collection.containsAll()}}|https://github.com/wildfly/wildfly-core/blob/0b51f7c1cce7286bf4f4e3f5c9250bf351bbdf1b/testsuite/patching/src/test/java/org/jboss/as/test/patching/BootLoggingPatchingStateTestCase.java#L151]. However if this is flipped the tests fail.
> It appears that the messages logged always contain the "WildFly" product id. Also the UUID for the failing examples seems to not be logged either.
> Example of logged messages for the "lp1" patch in the test:
> {code}
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> It looks like the same message is logged twice. However the following is what's expected:
> {code}
> lp1 cumulative patch ID is: base, one-off patches include: 50a820e4-3659-437d-86f2-fa1d64728adb
> WildFly cumulative patch ID is: 936c95a3-f08e-4fc0-9917-f7feead4ef25, one-off patches include: 00699c2c-84a5-4bdb-b469-8c2fd66afe2a, c6df609e-1620-4369-af48-8041d4be093f
> {code}
> I'm not sure if this is just an issue with the test or if there is a bug in patching.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (ELY-963) Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.sy... ]
Ilia Vassilev reassigned ELY-963:
---------------------------------
Assignee: Ilia Vassilev
> Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)
> -----------------------------------------------------------------------------------
>
> Key: ELY-963
> URL: https://issues.jboss.org/browse/ELY-963
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta24
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered.
> {code:java}
> private X509Certificate getClientCertificate() throws SaslException {
> if ((clientCertChain != null) && (clientCertChain.length > 0)) {
> return clientCertChain[0];
> } else if (clientCertUrl != null) {
> try {
> return EntityUtil.getCertificateFromUrl(clientCertUrl);
> } catch (IOException e) {
> throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException();
> }
> } else {
> throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9209) Patch needed for WF 10.1.0.Final for CVE-2016-4970
by John Hovell (JIRA)
[ https://issues.jboss.org/browse/WFLY-9209?page=com.atlassian.jira.plugin.... ]
John Hovell commented on WFLY-9209:
-----------------------------------
[~ctomc] - I have only tried image scanners that recognize JARs or OS packages that have been flagged in CVEs. It does not attempt any runtime exploit.
[~sannegrinovero] this is a reported CVE that has been public for over a year. I think based on what [~ctomc] is saying WF shouldn't actually be affected. I am just looking for some written documentation of that fact via an errata. The linked you provide states:
You should contact Red Hat Global Support Services if:
- You are unsure about how a known vulnerability affects a Red Hat product or service.
So I should contact Red Hat Global Support Services and not Red Hat Product Security?
> Patch needed for WF 10.1.0.Final for CVE-2016-4970
> --------------------------------------------------
>
> Key: WFLY-9209
> URL: https://issues.jboss.org/browse/WFLY-9209
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: John Hovell
> Assignee: Jason Greene
>
> Several 3rd party security scanners we use flag Wildfly 10.1.0.Final as containing the following DoS vulnerability:
> https://nvd.nist.gov/vuln/detail/CVE-2016-4970
> I have found a Redhat errata and bugzilla but neither references Wildfly specifically nor does CVE-2016-4970 turn up on a search here in Jira.
> https://access.redhat.com/security/cve/cve-2016-4970
> https://bugzilla.redhat.com/show_bug.cgi?id=1343616
> I am trying to understand if Wildfly team believes WF 10.1.0 is vulnerable and if so if it should be patched. I understand that WF 11 has an upgraded version of Netty which is not vulnerable to this CVE, but it is still in beta and security patches shouldn't need a major version upgrade.
> I am also trying to understand the official channel that the Wildfly project uses to track security errata as a search for "CVE" here only turns up ~3 other issues. Are the above Redhat links the place to look? And if so should Wildfly be marked as not affected, or why do they only refer to very very old versions of JBoss? I'd still be confused however how WF wouldn't be affected as it seems to contain wildfly/modules/system/layers/base/io/netty/main/netty-all-4.0.33.Final.jar which does not appear to be back-ported with a fix.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (LOGTOOL-101) Exception transformation
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ]
James Perkins updated LOGTOOL-101:
----------------------------------
Fix Version/s: 2.1.1.Final
(was: 2.1.0.Final)
> Exception transformation
> ------------------------
>
> Key: LOGTOOL-101
> URL: https://issues.jboss.org/browse/LOGTOOL-101
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
> Fix For: 2.1.1.Final
>
>
> I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine.
> Something like this:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause)
> {code}
> This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string.
> Note that I can almost do this now, except that there's no way to copy the exception stack:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause)
> {code}
> An alternative approach is to add an annotation for copying the stack trace:
> {code}
> @Message(id = 1234, "Binding to %s failed")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause)
> {code}
> Note that in this case the original exception message is lost. The next variant would preserve the message:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2)
> {code}
> And now to eliminate the duplication:
> {code}
> @Message(id = 1234, "Binding to %s failed: %s")
> IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause)
> {code}
> Note that I don't recall if @Pos is 1- or 0-based, so I guessed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)
by Scott Stark (JIRA)
[ https://issues.jboss.org/browse/WFLY-9212?page=com.atlassian.jira.plugin.... ]
Scott Stark updated WFLY-9212:
------------------------------
Description:
I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
The following line:
https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
I see this is due to a CallerPrincipal issue:
https://issues.jboss.org/browse/WFLY-3626
but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user facing container getUserPrincipal() type of API calls.
See the getPrincipalClass() unit test in this repo for an example of what is being tested:
https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
// Workaround authenticated JWTPrincipal not being installed as user principal
org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
Subject subject = jbSC.getUtil().getSubject();
jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
was:
I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
The following line:
https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
I see this is due to a CallerPrincipal issue:
https://issues.jboss.org/browse/WFLY-3626
but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user face container getUserPrincipal() call
See the getPrincipalClass() unit test in this repo for an example of what is being tested:
https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
// Workaround authenticated JWTPrincipal not being installed as user principal
org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
Subject subject = jbSC.getUtil().getSubject();
jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
> Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9212
> URL: https://issues.jboss.org/browse/WFLY-9212
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Scott Stark
> Assignee: Darran Lofthouse
>
> I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
> The following line:
> https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
> sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
> Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
> I see this is due to a CallerPrincipal issue:
> https://issues.jboss.org/browse/WFLY-3626
> but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user facing container getUserPrincipal() type of API calls.
> See the getPrincipalClass() unit test in this repo for an example of what is being tested:
> https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
> I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
> // Workaround authenticated JWTPrincipal not being installed as user principal
> org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
> Subject subject = jbSC.getUtil().getSubject();
> jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
> I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9212) Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object, Subject)
by Scott Stark (JIRA)
[ https://issues.jboss.org/browse/WFLY-9212?page=com.atlassian.jira.plugin.... ]
Scott Stark edited comment on WFLY-9212 at 8/9/17 2:08 PM:
-----------------------------------------------------------
For completeness, the complete workaround also requires reestablishing the roles from the authenticated subject, so that code snippets are:
{code:java}
// Workaround authenticated JWTPrincipal not being installed as user principal
// https://issues.jboss.org/browse/WFLY-9212
org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
Subject subject = jbSC.getUtil().getSubject();
jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
RoleGroup roles = extract(subject);
jbSC.getUtil().setRoles(roles);
/**
* Extract the Roles group and return it as a RoleGroup
* @param subject authenticated subject
* @return RoleGroup from "Roles"
*/
protected RoleGroup extract(Subject subject) {
Optional<Principal> match = subject.getPrincipals()
.stream()
.filter(g -> g.getName().equals(SecurityConstants.ROLES_IDENTIFIER))
.findFirst();
Group rolesGroup = (Group) match.get();
RoleGroup roles = new SimpleRoleGroup( rolesGroup );
return roles;
}
{code}
was (Author: starksm64):
For completeness, the complete workaround also requires reestablishing the roles from the authenticated subject, so that code snippets are:
{code:java}
// Workaround authenticated JWTPrincipal not being installed as user principal
// https://issues.jboss.org/browse/WFLY-9212
org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
Subject subject = jbSC.getUtil().getSubject();
jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
RoleGroup roles = extract(subject);
jbSC.getUtil().setRoles(roles);
/**
* Extract the Roles group and return it as a RoleGroup
* @param subject authenticated subject
* @return RoleGroup from "Roles"
*/
protected RoleGroup extract(Subject subject) {
Optional<Principal> match = subject.getPrincipals()
.stream()
.filter(g -> g.getName().equals(SecurityConstants.ROLES_IDENTIFIER))
.findFirst();
Group rolesGroup = (Group) match.get();
RoleGroup roles = new SimpleRoleGroup( rolesGroup );
return roles;
}
{code}
> Cannot control what principal JAASIdentityManagerImpl for SecurityContextUtil#createSubjectInfo(Principal, Object,Subject)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9212
> URL: https://issues.jboss.org/browse/WFLY-9212
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 10.1.0.Final
> Reporter: Scott Stark
> Assignee: Darran Lofthouse
>
> I have a custom JWT based auth method and JAAS login module that I'm testing with swarm which is using WFLY 10.1.0.Final. I am not able to install a custom Principal instance for retrieval via the JAX-RS javax.ws.rs.core.SecurityContext#getUserPrincipal() because of how the JAASIdentityManagerImpl#verifyCredential(final AccountImpl account, final Object credential) method populates the SecurityContext.SecurityContextUtil SubjectInfo.
> The following line:
> https://github.com/wildfly/wildfly/blob/c3332cec0c9bc5dc57899c2ae7ba26dd0...
> sc.getUtil().createSubjectInfo(incomingPrincipal, credential, subject);
> Is using the incomingPrincipal, which is derived from the simple AccountImpl wrapping of the incoming String id. In my call path, this is the user id before any authentication has happened as there is no originalPrincipal value on the AccountImpl, so it is not the best representation of the authenticated caller, and the wrapping Principal instance does not exist amongst the authenticated Subject#getPrincipals().
> I see this is due to a CallerPrincipal issue:
> https://issues.jboss.org/browse/WFLY-3626
> but one needs to be able to control what form of the authenticated userPrincipal that is returned by the user face container getUserPrincipal() call
> See the getPrincipalClass() unit test in this repo for an example of what is being tested:
> https://github.com/MicroProfileJWT/microprofile-jwt-auth-wfswarm/blob/f39...
> I can work around this by overriding the SubjectInfo by immediately after the auth mechanism has called the SecurityContext#authenticationComplete(...) using:
> // Workaround authenticated JWTPrincipal not being installed as user principal
> org.jboss.security.SecurityContext jbSC = SecurityContextAssociation.getSecurityContext();
> Subject subject = jbSC.getUtil().getSubject();
> jbSC.getUtil().createSubjectInfo(jwtPrincipal, bearerToken, subject);
> I have tried wrapping the Account passed into SecurityContext#authenticationComplete(...) and that has not worked so far, but I'll look again to see if there is something else I can override to achieve the desired behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months