[JBoss JIRA] (SECURITY-876) Web initiated logout doesn't clear authenticated identity in EJB
by Arjan t (JIRA)
Arjan t created SECURITY-876:
--------------------------------
Summary: Web initiated logout doesn't clear authenticated identity in EJB
Key: SECURITY-876
URL: https://issues.jboss.org/browse/SECURITY-876
Project: PicketBox
Issue Type: Bug
Reporter: Arjan t
Assignee: Stefan Guilhen
After having authenticated via JASPIC, calling {{HttpServletRequest#logout}} and then requesting the caller/user principal (all within the same request), WildFly 8.2 will correctly clear out the principal for the web context, but will NOT clear out the principal for the EJB context.
Cross-checking with the RI (GlassFish 4.0/4.1) reveals that there the EJB context is indeed cleared out.
As a workaround, calling the following code after logout (e.g. in an Undertow event handler for SecurityNotifications) will clear the EJB context, but this code should of course not be needed to be called by user apps:
{code:java}
SecurityContextAssociation.clearSecurityContext();
SecurityRolesAssociation.setSecurityRoles(null);
{code}
A reproducer for this issue is available at: https://github.com/arjantijms/javaee7-samples/blob/master/jaspic/ejb-prop...
For WildFly 8.2 this will print:
{noformat}
web username: test
EJB username: test
web username after logout: null
EJB username after logout: test
{noformat}
For GlassFish 4.0/4.1 this will print:
{noformat}
web username: test
EJB username: test
web username after logout: null
EJB username after logout: ANONYMOUS
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-2137) transaction services do not start in domain mode with jts enabled
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-2137?page=com.atlassian.jira.plugin.... ]
Michael Musgrove resolved WFLY-2137.
------------------------------------
Resolution: Cannot Reproduce Bug
The JIRA does not contain enough information for me to evaluate whether or not this is a bug.
> transaction services do not start in domain mode with jts enabled
> -----------------------------------------------------------------
>
> Key: WFLY-2137
> URL: https://issues.jboss.org/browse/WFLY-2137
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Michał Zegan
> Assignee: Michael Musgrove
> Fix For: 9.0.0.Beta1
>
>
> When launching the app server in domain mode when there is a transaction subsystem active with jts set to true, server shows an error that there's a circular dependency between services.
> I don't have any log to show this but it is easily reproducible.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-487) Instability in RespawnHttpTestCase
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-487?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-487:
------------------------------------------
Emmanuel Hugonnet 17:44 it seems that BufferPipeOutputStream may have a lock on the remoteconnection lock
Emmanuel Hugonnet 17:45 throught the RemoteConnection.RemoteWriteListener.send(
Emmanuel Hugonnet 17:47while closing the pendingChannels will lock the connection lock and then try to send something through the BufferPipeOutputStream
which is already locked
@DavidMLloyd ^^
David M. Lloyd 17:47 yeah
I acknowledge the problem
5.x is going to get rid of as many locks as possible
Emmanuel Hugonnet 17:48 but I'm afraid I don't have enough neurons left to find a way to break this
David M. Lloyd 17:48 I don't have a more immediate fix, it's a tricky problem
> Instability in RespawnHttpTestCase
> -----------------------------------
>
> Key: WFCORE-487
> URL: https://issues.jboss.org/browse/WFCORE-487
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha14
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Attachments: respawn-http-threads.txt
>
>
> We have the following error message in the traces:
> 2014-12-15 19:19:53,574 ERROR [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=32341&buildTyp...!
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFCORE-561:
------------------------------------
Since this has to be in wildfly-core and the transaction API is in wildfly proper, we'll have to do a new spec API.
> Class loading problem with XAResource and XADataSource
> ------------------------------------------------------
>
> Key: WFCORE-561
> URL: https://issues.jboss.org/browse/WFCORE-561
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha19
>
>
> We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
> The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
> One solution is to ensure that the {{javax.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{javax.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-561:
-------------------------------
Description:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{javax.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{javax.api}} module.
was:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
> Class loading problem with XAResource and XADataSource
> ------------------------------------------------------
>
> Key: WFCORE-561
> URL: https://issues.jboss.org/browse/WFCORE-561
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha19
>
>
> We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
> The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
> One solution is to ensure that the {{javax.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{javax.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource
by David Lloyd (JIRA)
David Lloyd created WFCORE-561:
----------------------------------
Summary: Class loading problem with XAResource and XADataSource
Key: WFCORE-561
URL: https://issues.jboss.org/browse/WFCORE-561
Project: WildFly Core
Issue Type: Bug
Components: Modules
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.0.0.Alpha19
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}}s and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-561) Class loading problem with XAResource and XADataSource
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-561?page=com.atlassian.jira.plugin... ]
David Lloyd updated WFCORE-561:
-------------------------------
Description:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
was:
We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}}s and strange CCEs under certain circumstances.
The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
> Class loading problem with XAResource and XADataSource
> ------------------------------------------------------
>
> Key: WFCORE-561
> URL: https://issues.jboss.org/browse/WFCORE-561
> Project: WildFly Core
> Issue Type: Bug
> Components: Modules
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: 1.0.0.Alpha19
>
>
> We define the JTA API in a module ({{java.transaction.api}}) but we neglect to redefine those classes in the {{javax.sql}} package which reference that API, including {{XADataSource}}, which can cause {{LinkageError}} and strange CCEs under certain circumstances.
> The isolated subgraph of classes from that package need to be added to either the {{java.transaction.api}} module or a new {{javax.sql.api}} module. Then measures must be taken to prevent the JDK's version of these classes from leaking out, a task complicated by the presence of the rowset API classes also sharing that package.
> One solution is to ensure that the {{jdk.api}} module includes a re-exported dependency on the module with the relocated classes which takes precedence over the system dependency, ensuring that the system classes never become visible. Another solution is to modify JBoss Modules to implement an XML mapping of the class filter concept, and then add class filter expressions to the {{module.xml}} of the {{jdk.api}} module.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
Arjan t commented on SECURITY-746:
----------------------------------
p.s.
There's a test for this case in the Java EE 7 samples project, which is indeed failing for WildFly 8.2. See here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/ejb-...
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: SECURITY-746
> URL: https://issues.jboss.org/browse/SECURITY-746
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by Arjan t (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
Arjan t commented on SECURITY-746:
----------------------------------
This is still a problem in WildFly 8.2, even though that one has some alignment with the security domain of the web module (see WFLY-3102).
The code in Picketbox has changed a bit from the report, but still after JASPIC has successfully authenticated in the web tier and then calls a method on a protected EJB, {{org.jboss.as.ejb3.security.SecurityContextInterceptor}} still tries to authenticate with {{org.jboss.as.security.service.SimpleSecurityManager}}.
This now happens here:
{code:java}
public class SecurityContextInterceptor implements Interceptor {
private final PrivilegedAction<Void> pushAction;
private final PrivilegedAction<Void> popAction;
public SecurityContextInterceptor(final SecurityContextInterceptorHolder holder) {
this.pushAction = new PrivilegedAction<Void>() {
@Override
public Void run() {
holder.securityManager.push(holder.securityDomain);
try {
if (holder.skipAuthentication == false) {
holder.securityManager.authenticate(holder.runAs, holder.runAsPrincipal, holder.extraRoles);
}
if (holder.principalVsRolesMap != null) {
SecurityRolesAssociation.setSecurityRoles(holder.principalVsRolesMap);
}
} catch (Throwable t) {
{code}
{{holder.securityManager.authenticate}} will be called. This now contains the following code:
{code:java}
private boolean authenticate(SecurityContext context, Subject subject) {
SecurityContextUtil util = context.getUtil();
SubjectInfo subjectInfo = getSubjectInfo(context);
if (subject == null) {
subject = new Subject();
}
Principal principal = util.getUserPrincipal();
Principal auditPrincipal = principal;
Object credential = util.getCredential();
Identity unauthenticatedIdentity = null;
boolean authenticated = false;
if (principal == null) {
unauthenticatedIdentity = getUnauthenticatedIdentity();
subjectInfo.addIdentity(unauthenticatedIdentity);
auditPrincipal = unauthenticatedIdentity.asPrincipal();
subject.getPrincipals().add(auditPrincipal);
authenticated = true;
} else {
subject.getPrincipals().add(principal);
}
if (authenticated == false) {
AuthenticationManager authenticationManager = context.getAuthenticationManager();
authenticated = authenticationManager.isValid(principal, credential, subject);
}
{code}
The 2nd line {{SubjectInfo subjectInfo = getSubjectInfo(context);}} will retrieve the authenticated identity as established by the JASPIC auth module, but instead of using it, it will call {{authenticationManager.isValid(principal, credential, subject);}}, which will call through to a JAAS login module.
This will now cause the following exception:
{noformat}
javax.ejb.EJBAccessException: JBAS013323: Invalid User
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:66) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:46) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:92) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
{noformat}
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: SECURITY-746
> URL: https://issues.jboss.org/browse/SECURITY-746
> Project: PicketBox
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
>
> After a user has successfully authenticated with JASPIC it's not possible to access any method in a secured EJB bean, irrespective of the actual security constraints.
> The problem is that when an EJB is "secured" an extra interceptor is added to the chain: {{org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor}}.
> This interceptor calls {{org.jboss.as.security.service.SimpleSecurityManager.push}}, which tries to establish a new stacked security context by attempting a login to a JAAS login module associated with the security domain.
> However, when the caller authenticated via a JASPIC auth module, there isn't necessarily such a JAAS login module (the JASPIC auth module is not required to call a JAAS login module, and even if it did it may not be the JAAS login module JBoss knows about).
> The problematic part in {{SimpleSecurityManager}}:
> {code}
> public void push(final String securityDomain, final String runAs, final String runAsPrincipal, final Set<String> extraRoles) {
> boolean contextPushed = false;
> boolean securityContextEstablished = false;
> final SecurityContext previous = SecurityContextAssociation.getSecurityContext();
> try {
> contexts.push(previous);
> contextPushed = true;
> SecurityContext current = establishSecurityContext(securityDomain);
> securityContextEstablished = true;
> if (previous != null) {
> current.setSubjectInfo(previous.getSubjectInfo());
> current.setIncomingRunAs(previous.getOutgoingRunAs());
> }
> RunAs currentRunAs = current.getIncomingRunAs();
> boolean trusted = currentRunAs != null && currentRunAs instanceof RunAsIdentity;
> if (trusted == false) {
>
> boolean authenticated = false;
> if (SecurityActions.remotingContextIsSet()) {
> // ...
> }
> // If we have a trusted identity no need for a re-auth.
> if (authenticated == false) {
> // THIS WILL EVENTUALLY ATTEMPT A JAAS LOGIN WHICH FAILS
> authenticated = authenticate(current, null);
> }
> {code}
> The (condensed) stack that will lead to an exception is the following:
> {noformat}
> javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(Principal, Object)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(Principal, Object, Subject)
> org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(Principal, Object, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SecurityContext, Subject)
> org.jboss.as.security.service.SimpleSecurityManager.push(String, String, String, Set<String>)
> org.jboss.as.ejb3.security.SecurityContextInterceptor.SecurityContextInterceptor(SecurityContextInterceptorHolder)
> {noformat}
> Since the {{SimpleSecurityManager}} is already doing a check to see if the call is remote or not, I wonder if it could not simply accept the existing security context as-is for local calls (not even start a new context) or just consider the existing security context as trusted for local calls just like a {{RunAS}} identity.
> Note that this depends on SECURITY-744 and SECURITY-745, since otherwise there is no valid security context at all.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4380) Remove usage of jboss-common-core in web services
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-4380:
---------------------------------
Summary: Remove usage of jboss-common-core in web services
Key: WFLY-4380
URL: https://issues.jboss.org/browse/WFLY-4380
Project: WildFly
Issue Type: Sub-task
Components: Web Services
Reporter: Tomaz Cerar
Assignee: Alessio Soldano
Fix For: 9.0.0.CR1
We are getting rid of this ultra old dependency.
Web services uses it in jbossws-common and jbossws-cxf-server
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months