[JBoss JIRA] (WFLY-4625) EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4625?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4625:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1243553|https://bugzilla.redhat.com/show_bug.cgi?id=1243553] from VERIFIED to CLOSED
> EJB SecurityContextInterceptor attempts JAAS login which doesn't work for JASPIC authentications
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4625
> URL: https://issues.jboss.org/browse/WFLY-4625
> Project: WildFly
> Issue Type: Feature Request
> Reporter: arjan tijms
> Assignee: Stefan Guilhen
> Labels: authentication, ejb, jaspi, jaspic, security, security-context
> Fix For: 9.0.0.CR2, 10.0.0.Alpha2
>
>
> 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
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-632) Subsystem deployment undeployed at startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-632?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-632:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1271673|https://bugzilla.redhat.com/show_bug.cgi?id=1271673] from VERIFIED to CLOSED
> Subsystem deployment undeployed at startup
> ------------------------------------------
>
> Key: WFCORE-632
> URL: https://issues.jboss.org/browse/WFCORE-632
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Beta3, 1.0.0.Beta4
> Reporter: Stan Silvert
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 1.0.0.Beta4
>
>
> {noformat}
> @BrianStansberry The "mixed approach" doesn't seem to work any more. https://developer.jboss.org/wiki/ExtendingAS7
> @BrianStansberry I'm using this to deploy keycloak WAR from the subsystem.
> @BrianStansberry As soon as the server is started, something is calling stopService() on the Keycloak WAR.
> Tomaz Cerar
> 1:15 PM
> @StanSilvert are you still working on AS7? https://docs.jboss.org/author/display/WFLY8/Extending+WildFly+8
> Stan Silvert
> 1:16 PM
> @ctomc No. this is WildFly 9. It still works on WildFly 8.
> Tomaz Cerar
> 1:16 PM
> ah the war deployment, that could be regression
> Brian Stansberry
> 1:17 PM
> @ctomc how so?
> Stan Silvert
> 1:17 PM
> FYI. I did a Thread.dumpStack() and got this:
> 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) java.lang.Exception: Stack trace
> 13:11:35,173 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.dumpStack(Thread.java:1329)
> 13:11:35,174 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.Host.unregisterDeployment(Host.java:168)
> 13:11:35,176 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:
> 113)
> 13:11:35,179 ERROR [stderr] (MSC service thread 1-3) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
> 13:11:35,181 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.Serv
> iceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> 13:11:35,184 ERROR [stderr] (MSC service thread 1-3) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 13:11:35,186 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 13:11:35,188 ERROR [stderr] (MSC service thread 1-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 13:11:35,190 ERROR [stderr] (MSC service thread 1-3) at java.lang.Thread.run(Thread.java:745)
> Hide full text
> Tomaz Cerar
> 1:18 PM
> @BrianStansberry just reffering that war deployment from subsystem should still work
> 1:19 PM
> Jason Greene joined the room.
> Tomaz Cerar
> 1:19 PM
> @StanSilvert what happens? as that thread dump makes no sense
> Stan Silvert
> 1:21 PM
> http://pastebin.com/xQ2DNzEe
> The WAR is simply undeployed as soon as WildFly finishes startup.
> Brian Stansberry
> 1:22 PM
> @StanSilvert can you give me a link to your code that's doing the deploy stuff?
> Stan Silvert
> 1:22 PM
> just a sec
> Stan Silvert
> 1:24 PM
> https://github.com/keycloak/keycloak/tree/master/integration
> The code that creates the operation is https://github.com/keycloak/keycloak/blob/master/integration
> AuthServerUtil ^^^
> click on the second link
> 1:27 PM
> Darran Lofthouse left the room.
> Brian Stansberry
> 1:27 PM
> @StanSilvert are you doing overlay stuff? I see some code there re: overlays
> Stan Silvert
> 1:28 PM
> Yes, but not in this instance.
> Brian Stansberry
> 1:28 PM
> ok. I'm asking just because that would add more complexity, better scope for some service dependency going missing, triggering stop
> Stan Silvert
> 1:29 PM
> For this simple case there are no overlays.
> Brian Stansberry
> 1:29 PM
> @StanSilvert interesting, your log looks like it's a true undeploy op, not just a service stop
> Tomaz Cerar
> 1:30 PM
> @BrianStansberry should we use 6.x.0 or 6.x.latest for tranformers testing?
> Tomaz Cerar goes get some diner
> Stan Silvert
> 1:30 PM
> @BrianStansberry If that's the case then maybe some condition is triggering my own undeploy operation.
> @BrianStansberry I'll look into that and see what I find.
> Brian Stansberry
> 1:31 PM
> @ctomc 6.x.0 is ok by me; chasing CPs is too much hassle
> @StanSilvert note this:
> 13:11:35,294 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "main-auth-server.war" (runtime-name: "main-auth-server.war")
> the thread -- DeploymentScanner-threads - 1
> looks like your deployment is exposed to the scanner?
> oh, here's a guess!
> the scanner sees "persistent" => false and treats it as under scanner control
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1304) WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1304?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1304:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1299189|https://bugzilla.redhat.com/show_bug.cgi?id=1299189] from VERIFIED to CLOSED
> WFLYCTL0013: Operation ("clean-obsolete-content") failed .. StringIndexOutOfBoundsException when OS puts metadata files in content repo
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1304
> URL: https://issues.jboss.org/browse/WFCORE-1304
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brad Maxwell
> Assignee: Chao Wang
> Fix For: 2.0.8.Final
>
>
> Mac OS can put .DS_Store files into the content repo directory. This can also be reproduced on Linux by creating a file under the content dir and when clean-obsolete-content() runs it will log this error. It seems it runs every 10 minutes.
> {code}
> 22:59:48,289 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 1) WFLYDR0009: Content /Users/bradley/Desktop/wildfly-10.0.0.CR5/standalone/data/content/9b/.DS_Store is obsolete and will be removed
> 22:59:48,290 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 1) WFLYCTL0013: Operation ("clean-obsolete-content") failed - address: ([]): java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> at java.lang.String.charAt(String.java:658)
> at org.jboss.as.repository.HashUtil.hexStringToByteArray(HashUtil.java:62)
> at org.jboss.as.repository.ContentReference.getHash(ContentReference.java:68)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:365)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.markAsObsolete(ContentRepository.java:427)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.cleanObsoleteContent(ContentRepository.java:403)
> at org.jboss.as.server.operations.CleanObsoleteContentHandler.execute(CleanObsoleteContentHandler.java:76)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
> at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner.cleanObsoleteContent(ContentRepositoryCleaner.java:132)
> at org.jboss.as.server.deployment.ContentRepositoryCleaner$ContentRepositoryCleanerTask.run(ContentRepositoryCleaner.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 22:59:48,292 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 1) WFLYSRV0216: Error cleaning obsolete content WFLYCTL0158: Operation handler failed: java.lang.StringIndexOutOfBoundsException: String index out of range: 11
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6441) naming context is not setup when starting the persistence unit
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6441?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6441:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1320132|https://bugzilla.redhat.com/show_bug.cgi?id=1320132] from VERIFIED to CLOSED
> naming context is not setup when starting the persistence unit
> --------------------------------------------------------------
>
> Key: WFLY-6441
> URL: https://issues.jboss.org/browse/WFLY-6441
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: JBoss AS7 7.1.1.Final, JBoss AS7 7.2.0.Final, 9.0.2.Final, 10.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> ookup of env-entry throws NameNotFoundException during persistence unit startup
> Version-Release number of selected component (if applicable):
> How reproducible:
> always
> Steps to Reproduce:
> 1. add env-entry in application.xml
> 2. try to lookup during persistent unit startup, e.g.
> public class MyType implements UserType {
> ...
> @Override
> public int[] sqlTypes() {
> try {
> Object ctx = new InitialContext().lookup("java:app/env");
> log.info("java:app/env from JPA = " + ctx);
> } catch (Exception e) {
> log.error("unable to get java:app/env from JPA", e);
> }
> return new int[] { Types.VARCHAR };
> }
> Actual results:
> NameNotFoundException
> Expected results:
> value of env-entry is available
> Additional info:
> On 21.03.2016 23:47, Stuart Douglas wrote:
> > This should fix it (I think): https://github.com/stuartwdouglas/wildfly/tree/jpa-java-namespace
> >
> > Stuart
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1495) server instances cannot find keytab during domain startup
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1495?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1495:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1328997|https://bugzilla.redhat.com/show_bug.cgi?id=1328997] from VERIFIED to CLOSED
> server instances cannot find keytab during domain startup
> ---------------------------------------------------------
>
> Key: WFCORE-1495
> URL: https://issues.jboss.org/browse/WFCORE-1495
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Derek Horton
> Assignee: Vlado Pakan
> Fix For: 3.0.0.Alpha2
>
> Original Estimate: 4 days
> Time Spent: 3 days, 4 hours
> Remaining Estimate: 4 hours
>
> In domain mode, the server instances cannot find the keytab if the ApplicationRealm is configured to use kerberos as the server-identity:
> {code}
> <security-realm name="ApplicationRealm">
> <server-identities>
> <kerberos>
> <keytab principal="remote/imahost.imadomain.net@VM29" path="/path/to/keytab"/>
> </kerberos>
> </server-identities>
> <authentication>
> <kerberos remove-realm="true"/>
> </authentication>
> <authorization>
> <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
> </authorization>
> </security-realm>
> {code}
> This results in the following error and the server instances fail to start:
> [Server:server-one] 15:10:35,360 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("validate-authentication") failed - address: ([
> [Server:server-one] ("core-service" => "management"),
> [Server:server-one] ("security-realm" => "ApplicationRealm")
> [Server:server-one] ]) - failure description: "WFLYDM0094: Kerberos is enabled for authentication on security realm 'ApplicationRealm' but no Keytab has been added to the server-identity."
> [Server:server-one] 15:10:35,376 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-1119) ManagedDatagramSocketBinding throw NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1119?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1119:
-------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1280235|https://bugzilla.redhat.com/show_bug.cgi?id=1280235] from VERIFIED to CLOSED
> ManagedDatagramSocketBinding throw NPE
> --------------------------------------
>
> Key: WFCORE-1119
> URL: https://issues.jboss.org/browse/WFCORE-1119
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR8
> Reporter: Stefan Dilk
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> i think i have found the same bug as in WFCORE-1033 but in another method.
> in the previous bug the bind method was the problem, here i have the same NPE in the close method. there is no null check to registry as in the bind method.
> {noformat}
> [Server:mgmt-1-prod] 2015-11-10 00:37:15,454 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector:
> java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:9
> 6)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [Server:mgmt-1-prod] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:mgmt-1-prod] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:mgmt-1-prod] at java.lang.Thread.run(Thread.java:745)
> [Server:mgmt-1-prod] Caused by: java.lang.NullPointerException
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> [Server:mgmt-1-prod] at java.net.DatagramSocket.<init>(DatagramSocket.java:245)
> [Server:mgmt-1-prod] at org.jboss.as.network.ManagedDatagramSocketBinding.<init>(ManagedDatagramSocketBinding.java:41)
> [Server:mgmt-1-prod] at org.jboss.as.network.SocketBindingManagerImpl.createDatagramSocket(SocketBindingManagerImpl.java:87)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:103)
> [Server:mgmt-1-prod] at org.jboss.as.clustering.jgroups.ManagedSocketFactory.createDatagramSocket(ManagedSocketFactory.java:113)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createDatagramSocketWithBindPort(UDP.java:487)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.createSockets(UDP.java:361)
> [Server:mgmt-1-prod] at org.jgroups.protocols.UDP.start(UDP.java:270)
> [Server:mgmt-1-prod] at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.startStack(JChannel.java:890)
> [Server:mgmt-1-prod] at org.jgroups.JChannel._preConnect(JChannel.java:553)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:288)
> [Server:mgmt-1-prod] at org.jgroups.JChannel.connect(JChannel.java:279)
> [Server:mgmt-1-prod] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> [Server:mgmt-1-prod] ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months