[JBoss JIRA] (WFLY-1788) RBAC: role combination doesn't work
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-1788:
-----------------------------------
Summary: RBAC: role combination doesn't work
Key: WFLY-1788
URL: https://issues.jboss.org/browse/WFLY-1788
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Reporter: Ladislav Thon
Assignee: Ladislav Thon
[This issue was in fact found on 2013-07-02 and is being filled now only for tracking purposes.]
Combining multiple roles doesn't work, as {{ManagementPermissionCollection(CombinationManagementPermission)}} will never {{imply}} a {{ManagementPermissionCollection(SimpleManagementPermission)}}. See TODOs in {{DefaultPermissionFactory}} and {{ManagementPermissionCollection}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1787) Patching: setting module path for CLI in offline mode
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1787:
----------------------------------
Summary: Patching: setting module path for CLI in offline mode
Key: WFLY-1787
URL: https://issues.jboss.org/browse/WFLY-1787
Project: WildFly
Issue Type: Bug
Reporter: Jan Martiska
Assignee: Emanuel Muckenhuber
Currently it is not possible to specify a module path for jboss-cli.sh in offline mode when dealing with patches.
The consequence is, when you work with patches through offline CLI invoked from a different Wildfly installation than the one you are working with (and therefore specifying --distribution), it will take into account the module path of its own installation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1442) Web console branding across community and product versions
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1442?page=com.atlassian.jira.plugin.... ]
Harald Pehl reopened WFLY-1442:
-------------------------------
Backport to 1.5.x
> Web console branding across community and product versions
> -----------------------------------------------------------
>
> Key: WFLY-1442
> URL: https://issues.jboss.org/browse/WFLY-1442
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
> Labels: console_1.5.4
>
> Define a way to specify the branding for the web console across different community and product versions. The name and version used for the branding should be read from the {{product-name}} and {{product-version}} attributes of the root DMR resource. Regarding the logo there are different options:
> # Use a unique logo for the web console across all community and products / versions
> # Choose between a community (WildFly) and a product logo (RedHat)
> # Hold up all logos for any community / product version in the HAL release stream and choose dynamically.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (AS7-4217) RemoteConnectionFactory is not found when looking up in a remote client
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4217?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated AS7-4217:
--------------------------------------
Forum Reference: https://community.jboss.org/message/830681#830681
> RemoteConnectionFactory is not found when looking up in a remote client
> -----------------------------------------------------------------------
>
> Key: AS7-4217
> URL: https://issues.jboss.org/browse/AS7-4217
> Project: Application Server 7
> Issue Type: Bug
> Components: JMS
> Affects Versions: 7.1.1.Final
> Reporter: Ondřej Chaloupka
> Assignee: Stuart Douglas
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> I do lookup for RemoteConnectionFactory firstly locally in container and secondary via remote client. Then the second (remote one) lookup for RemoteConnectionFactory fails with exception:
> {code}
> javax.naming.NamingException: Failed to lookup [Root exception is java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy]
> at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:392)
> at org.jboss.as.test.integration.ee.remotelookup.LookupTestCase.test2(LookupTestCase.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
> Caused by: java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:138)
> at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61)
> at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:128)
> at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: an exception which occurred:
> in field loadBalancingPolicy
> in field serverLocator
> in object org.hornetq.jms.client.HornetQJMSConnectionFactory@d67f82
> {code}
> Please check my test reproducer: https://github.com/ochaloup/jboss-as/commit/1a1605f6ad4e860789d704d682ff6...
> The exception is thrown on line: https://github.com/ochaloup/jboss-as/blob/1a1605f6ad4e860789d704d682ff6e6...
> Tested with standalone-full.xml. Command to run the test: ./integration-tests.sh clean install -Dts.noSmoke -Dts.basic -Dtest=org.jboss.as.test.integration.ee.remotelookup.*
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1769) 2 config updates for OpenJDK 8
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1769?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1769:
------------------------------------------
PR created : https://github.com/wildfly/wildfly/pull/4861
> 2 config updates for OpenJDK 8
> ------------------------------
>
> Key: WFLY-1769
> URL: https://issues.jboss.org/browse/WFLY-1769
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Reporter: Juergen Zimmermann
> Assignee: David Lloyd
>
> JDK 8 uses the Javascript Engine Nashorn instead of Rhino in JDK 7 (and 6).
> Therefore, 2 additional config lines are required to support JDK 8 in addition to JDK 7:
> After making the following 2 config updates for bean validation my web app is running with WildFly and OpenJDK 8:
> 1) In modules/system/layers/base/sun/jdk/main/module.xml: add the following <path> declaration as the 2nd subtag inside <paths>, i.e. after the "com/sun/script/javascript" for JDK 7:
> {code}
> <path name="jdk/nashorn/api/scripting"/>
> {code}
> 2) In modules/system/layers/base/sun/jdk/main/service-loader-resources/META-INF/services/javax.script.ScriptEngineFactory add the following line as the 2nd service, i.e. as a alternative service for JDK 7:
> {code}
> jdk.nashorn.api.scripting.NashornScriptEngineFactory
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (WFLY-1686) Use HAL release stream version number in console footer
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1686?page=com.atlassian.jira.plugin.... ]
Harald Pehl updated WFLY-1686:
------------------------------
Description:
Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
{code}
Core Console 1.5.4.Final --> HAL Release Stream 1.5.4.Final
--> HAL Release Stream 1.5.5.Final
{code}
was:
Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
{code}
Core Console 1.6.3.Final --> HAL Release Stream 1.6.3.1.Final
--> HAL Release Stream 1.6.3.2.Final
{code}
> Use HAL release stream version number in console footer
> -------------------------------------------------------
>
> Key: WFLY-1686
> URL: https://issues.jboss.org/browse/WFLY-1686
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
>
> Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
> {code}
> Core Console 1.5.4.Final --> HAL Release Stream 1.5.4.Final
> --> HAL Release Stream 1.5.5.Final
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (SECURITY-746) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/SECURITY-746?page=com.atlassian.jira.plug... ]
arjan tijms updated SECURITY-746:
---------------------------------
Description:
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.
was:
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.
> 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
> Security Level: Public(Everyone can see)
> Reporter: arjan tijms
> Assignee: Anil Saldhana
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months