[JBoss JIRA] (WFLY-8959) Clean up managed domain handling of the transaction subsystem's 'probe' operation
by Martin Simka (JIRA)
Martin Simka created WFLY-8959:
----------------------------------
Summary: Clean up managed domain handling of the transaction subsystem's 'probe' operation
Key: WFLY-8959
URL: https://issues.jboss.org/browse/WFLY-8959
Project: WildFly
Issue Type: Sub-task
Components: Transactions
Reporter: Martin Simka
Assignee: Michael Musgrove
Subtask for this item from the parent issue:
{quote}
The transaction subsystem's "probe" operation. A read-only, runtime-only op registered on the profile resource but which is functionally a no-op if invoked on the profile resource. But WFCORE-2858 would mean this now gets rolled out to all servers in the domain that use the profile, triggering an actual probe on all. So, if we do WFCORE-2858 we could:
a) Accept this, and let the op roll out. That should be an RFE though, with analysis that rolling it out would be harmless.
b) Remove the op from the profile. It never did anything useful (just a no-op that isn't rolled out) so removing it is only
a semi-breaking change.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
Choice c) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) and b) still options for the future, so that's what will be done as part of this work.
{quote}
The parent issue will do choice c); this issue is to decide the final status.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8958) Clean up managed domain handling of JSFImplListHandler
by Martin Simka (JIRA)
Martin Simka created WFLY-8958:
----------------------------------
Summary: Clean up managed domain handling of JSFImplListHandler
Key: WFLY-8958
URL: https://issues.jboss.org/browse/WFLY-8958
Project: WildFly
Issue Type: Sub-task
Components: JSF
Reporter: Martin Simka
Assignee: Farah Juma
Subtask for this item from the parent issue:
{quote}
The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is not the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
d) We could just stop registering it on the profile, but that's a loss of functionality.
Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
{quote}
The parent task is going to do choice b) as a temp thing; this task is decide about the rest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8958) Clean up managed domain handling of JSFImplListHandler
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8958?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFLY-8958:
-------------------------------
Parent: (was: WFLY-8849)
Issue Type: Bug (was: Sub-task)
> Clean up managed domain handling of JSFImplListHandler
> ------------------------------------------------------
>
> Key: WFLY-8958
> URL: https://issues.jboss.org/browse/WFLY-8958
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Martin Simka
> Assignee: Farah Juma
>
> Subtask for this item from the parent issue:
> {quote}
> The JSF subsystem's "list-active-jsf-impl" op. A read-only, runtime-only op that does runtime work (scanning modules) in Stage.MODEL on the profile resource. Lots of rules being broken! What this op does now if invoked against the profile is tell you what jsf impls are present on the DC. Which is not the same thing as telling you what impls are present on "the domain" since different hosts in the domain can have different sets of modules. So the op needs a rethink.
> a) If we correct the Stage.MODEL problem, we can't do WFCORE-2849. So we need to choose between the two.
> b) If we do WFCORE-2858, this op will now start getting rolled out to the domain servers resulting in getting data from all servers. This is arguably the correct behavior, as now the user learns the true situation in the domain, not just on the DC. But if we decide we don't want that we'll need to add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> c) If we do roll it out to the servers we can consider having it no longer do runtime work on the profile; i.e. don't analyze the DC, just the servers. That would remove the conflict with WFCORE-2849, but would be an incompatible change in behavior. I find it hard to believe anyone would be using this op in scripts though; not against the profile.
> d) We could just stop registering it on the profile, but that's a loss of functionality.
> Choice b) would let WFCORE-2858 go forward and preserve the status quo for this op, with a) c) and d) still options for the future.
> {quote}
> The parent task is going to do choice b) as a temp thing; this task is decide about the rest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8957) Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
by Martin Simka (JIRA)
Martin Simka created WFLY-8957:
----------------------------------
Summary: Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
Key: WFLY-8957
URL: https://issues.jboss.org/browse/WFLY-8957
Project: WildFly
Issue Type: Sub-task
Components: JMS
Reporter: Martin Simka
Assignee: Jeff Mesnil
Subtask for the following items from the parent issue:
{quote}
8) The messaging-activemq broadcast-group resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Task for this is to make a decision.
{quote}
9) The messaging-activemq broadcast-group resource also has problematic a get-connector-pairs-as-json op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
{quote}
10) The messaging-activemq cluster-connection resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
options here:
a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
b) Correct the description of these to declare runtime-only.
{quote}
Nothing was done re: this in the parent task.
{quote}
11) The messaging-activemq cluster-connection resource also has problematic a get-nodes op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
a) Remove the op from the profile resource. It never worked anyway.
b) Allow them to roll out. This would be new behavior though.
c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
{quote}
As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8957) Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
by Martin Simka (JIRA)
[ https://issues.jboss.org/browse/WFLY-8957?page=com.atlassian.jira.plugin.... ]
Martin Simka updated WFLY-8957:
-------------------------------
Parent: (was: WFLY-8849)
Issue Type: Bug (was: Sub-task)
> Clean up managed domain handling of messaging-activemq broadcast-group and cluster-connection runtime-only ops
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8957
> URL: https://issues.jboss.org/browse/WFLY-8957
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Simka
> Assignee: Jeff Mesnil
>
> Subtask for the following items from the parent issue:
> {quote}
> 8) The messaging-activemq broadcast-group resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
> options here:
> a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
> b) Correct the description of these to declare runtime-only.
> {quote}
> Task for this is to make a decision.
> {quote}
> 9) The messaging-activemq broadcast-group resource also has problematic a get-connector-pairs-as-json op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
> a) Remove the op from the profile resource. It never worked anyway.
> b) Allow them to roll out. This would be new behavior though.
> c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
> {quote}
> As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
> {quote}
> 10) The messaging-activemq cluster-connection resource has problematic 'start' and 'stop' ops. These are not registered as runtime-only, but they are. They are registered on the profile resource and are not read-only, so the DC rolls them out to the domain. So, they are pre-existing ops that break the no-runtime-only-on-profile rule that WFCORE-389 is about rescinding. We have two
> options here:
> a) remove these ops on the profile as violations of the no-runtime-only-on-profile rule. This would be a breaking change. But it may be the correct thing to do anyway if it is unsafe to invoke these on the profile and have that roll out to all servers.
> b) Correct the description of these to declare runtime-only.
> {quote}
> Nothing was done re: this in the parent task.
> {quote}
> 11) The messaging-activemq cluster-connection resource also has problematic a get-nodes op. This is a read-only op so it currently will not roll out. It will also fail if executed against the profile resource, as it fails if there is no activemq server present. So, the options here are:
> a) Remove the op from the profile resource. It never worked anyway.
> b) Allow them to roll out. This would be new behavior though.
> c) Add OperationEntry.Flag.HOST_CONTROLLER_ONLY to the operation definition to prevent that rollout.
> IMHO option c) is kind of silly, leaving a broken op in place, but it's a valid "emergency" step to prevent roll out inadvertently being turned on while a decision between a) and b) is made. So that's what will be done as part of this work.
> {quote}
> As part of the parent task, option c) will be put in place. Task here is to decide final resolution.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1618) DMN sort function doesn't work on IBM JDK
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1618?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-1618:
---------------------------------------
When the "precedes" parameter is omitted, the function should use natural order for sorting.
Fixed.
> DMN sort function doesn't work on IBM JDK
> -----------------------------------------
>
> Key: DROOLS-1618
> URL: https://issues.jboss.org/browse/DROOLS-1618
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Edson Tirelli
> Labels: reported-by-qe
> Fix For: 7.1.0.Final
>
>
> When running DMN test combination _sort( list : [3, 1, 4, 5, 2] )_ from FEELFunctionsTest class on IBM JDK, the test fails, because the correct sort method cannot be invoked.
> On IBM JDK, the combination tries to invoke method [1] from SortFunction class, which is incorrect, because the second method with just one parameter should be invoked. This behaviour is influenced by IBM JDK returning methods from call [2] in different order.
> Notes from debugging:
> This check [3] pass because the array there is 3 items long although the last item is not populated. This array is created from this method call [4].
> [1] https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-feel/src/m...
> [2] https://github.com/kiegroup/drools/blob/ec038e19867d0f4f13f9ddc508f3bbab4...
> [3]https://github.com/kiegroup/drools/blob/ec038e19867d0f4f13f9ddc508f3bba...
> [4] https://github.com/kiegroup/drools/blob/ec038e19867d0f4f13f9ddc508f3bbab4...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2892) Regression in legacy security in DR17, Kerberos for CLI
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2892?page=com.atlassian.jira.plugi... ]
Darran Lofthouse resolved WFCORE-2892.
--------------------------------------
Resolution: Cannot Reproduce Bug
Resolving as I can not reproduce this.
My configuration is: -
<system-properties>
<property name="sun.security.krb5.debug" value="true"/>
<property name="java.security.krb5.realm" value="ELYTRON.ORG"/>
<property name="java.security.krb5.kdc" value="kdc.elytron.org"/>
</system-properties>
<security-realm name="ManagementRealm">
<server-identities>
<kerberos>
<keytab principal="remote/test-server.elytron.org(a)ELYTRON.ORG" path="/home/darranl/src/kerberos/remote-test-server.keytab" debug="true"/>
</kerberos>
</server-identities>
<authentication>
<local default-user="$local"/>
<kerberos remove-realm="true"/>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization map-groups-to-roles="false">
<properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
I use the following command to execute the CLI: -
./jboss-cli.sh --controller=test-server.elytron.org -Djava.security.krb5.realm=ELYTRON.ORG -Djava.security.krb5.kdc=kdc.elytron.org -Dsun.security.krb5.debug=true -Djavax.security.auth.useSubjectCredsOnly=false --no-local-auth --user=darranl --password=password1!
Where the principal is invalid on the Kerberos identity then Kerberos authentication is successful when the CLI connects, when the principal is invalid then Digest authentication is successful.
> Regression in legacy security in DR17, Kerberos for CLI
> --------------------------------------------------------
>
> Key: WFCORE-2892
> URL: https://issues.jboss.org/browse/WFCORE-2892
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta23
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Beta27
>
>
> User impact: User relying on fallback authentication mechanism in case of Kerberos can't.
> This worked well in DR16.
> When GSSAPI mechanism fails other mechanism e.g. PLAIN doesn't occure.
> {code:title=server.log}
> 14:47:03,078 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='GSSAPI' host-name='localhost.localdomain' protocol='remote'
> 14:47:03,078 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) configuredMaxReceiveBuffer=16777215
> 14:47:03,078 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) relaxComplianceChecks=false
> 14:47:03,078 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) QOP={AUTH}
> 14:47:03,078 TRACE [org.wildfly.security.sasl.gssapi.server] (management I/O-2) Obtaining GSSCredential for the service from callback handler...
> 14:47:03,078 TRACE [org.jboss.as.domain.management.security] (management I/O-2) Selected KeytabService with principal 'remote/localhost.localdomain(a)WRONG_REALM.ORG' for host 'localhost.localdomain'
> 14:47:03,079 INFO [stdout] (management I/O-2) Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt false ticketCache is null isInitiator false KeyTab is /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.5505588796137857648.keytab refreshKrb5Config is false principal is remote/localhost.localdomain(a)WRONG_REALM.ORG tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> 14:47:03,079 INFO [stdout] (management I/O-2) principal is remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,079 INFO [stdout] (management I/O-2) Will use keytab
> 14:47:03,079 INFO [stdout] (management I/O-2) Commit Succeeded
> 14:47:03,079 INFO [stdout] (management I/O-2)
> 14:47:03,079 INFO [stdout] (management I/O-2) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.5505588796137857648.keytab for remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,080 INFO [stdout] (management I/O-2) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.5505588796137857648.keytab for remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,080 INFO [stdout] (management I/O-2) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.5505588796137857648.keytab for remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,080 INFO [stdout] (management I/O-2) Found KeyTab /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb.5505588796137857648.keytab for remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,080 TRACE [org.wildfly.security] (management I/O-2) Handling ServerCredentialCallback: successfully obtained credential type type=class org.wildfly.security.credential.GSSKerberosCredential, algorithm=null, params=null
> 14:47:03,080 TRACE [org.jboss.remoting.endpoint] (management I/O-2) Allocated tick to 9 of endpoint "localhost:MANAGEMENT" <15985cc1> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor@211c95d4)
> 14:47:03,081 INFO [stdout] (management task-6) Entered Krb5Context.acceptSecContext with state=STATE_NEW
> 14:47:03,082 INFO [stdout] (management task-6) Looking for keys for: remote/localhost.localdomain(a)WRONG_REALM.ORG
> 14:47:03,083 TRACE [org.jboss.remoting.remote.server] (management task-6) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05031: [GSSAPI] Unable to accept SASL client message [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96)]
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateMessage(GssapiServer.java:152)
> at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180)
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateResponse(GssapiServer.java:121)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:57)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:467)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:891)
> 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)
> Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96)
> at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at org.wildfly.security.sasl.gssapi.GssapiServer.evaluateMessage(GssapiServer.java:131)
> ... 12 more
> Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:278)
> at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149)
> at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
> at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
> ... 15 more
> 14:47:03,083 TRACE [org.wildfly.security.sasl.gssapi.server] (management task-6) dispose
> 14:47:03,083 TRACE [org.wildfly.security] (management task-6) Handling AuthenticationCompleteCallback: fail
> 14:47:03,084 TRACE [org.jboss.remoting.endpoint] (management task-6) Resource closed count 00000008 of endpoint "localhost:MANAGEMENT" <15985cc1> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor@211c95d4)
> 14:47:03,084 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 5 bytes
> 14:47:03,084 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 14:47:03,084 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Shut down writes on channel
> 14:47:03,086 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 14:47:03,086 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 14:47:03,086 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF
> 14:47:03,087 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream
> 14:47:03,108 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) CLI executor output:
> 14:47:03,109 INFO [org.jboss.eapqe.krbldap.eap7.utils.CustomCLIExecutor] (main) Java config name: /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb/krb5-1708048015373854835.conf
> Loaded from Java config
> >>>KinitOptions cache name is /home/mchoma/workspace/git-repositories/tests-ldap-kerberos-eap7/eap7/target/krb5cc
> >>>DEBUG <CCacheInputStream> client principal is hnelson30d3d46a-214b-4b2d-903e-c484ebab7908(a)JBOSS.ORG
> >>>DEBUG <CCacheInputStream> server principal is krbtgt/JBOSS.ORG(a)JBOSS.ORG
> >>>DEBUG <CCacheInputStream> key type: 17
> >>>DEBUG <CCacheInputStream> auth time: Tue May 02 14:46:23 CEST 2017
> >>>DEBUG <CCacheInputStream> start time: Tue May 02 14:46:23 CEST 2017
> >>>DEBUG <CCacheInputStream> end time: Tue May 02 22:46:23 CEST 2017
> >>>DEBUG <CCacheInputStream> renew_till time: null
> >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH;
> Found ticket for hnelson30d3d46a-214b-4b2d-903e-c484ebab7908(a)JBOSS.ORG to go to krbtgt/JBOSS.ORG(a)JBOSS.ORG expiring on Tue May 02 22:46:23 CEST 2017
> Entered Krb5Context.initSecContext with state=STATE_NEW
> Service ticket not found in the subject
> >>> Credentials acquireServiceCreds: same realm
> default etypes for default_tgs_enctypes: 17.
> >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KdcAccessibility: reset
> >>> KrbKdcReq send: kdc=localhost.localdomain UDP:6088, timeout=5000, number of retries =3, #bytes=648
> >>> KDCCommunication: kdc=localhost.localdomain UDP:6088, timeout=5000,Attempt =1, #bytes=648
> >>> KrbKdcReq send: #bytes read=634
> >>> KdcAccessibility: remove localhost.localdomain:6088
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> >>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000
> >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
> Krb5Context setting mySeqNumber to: 23519002
> Krb5Context setting peerSeqNumber to: 0
> Created InitSecContextToken:
> 0000: 01 00 6E 82 02 2C 30 82 02 28 A0 03 02 01 05 A1 ..n..,0..(......
> 0010: 03 02 01 0E A2 07 03 05 00 00 00 00 00 A3 82 01 ................
> 0020: 2C 61 82 01 28 30 82 01 24 A0 03 02 01 05 A1 0B ,a..(0..$.......
> 0030: 1B 09 4A 42 4F 53 53 2E 4F 52 47 A2 2A 30 28 A0 ..JBOSS.ORG.*0(.
> 0040: 03 02 01 00 A1 21 30 1F 1B 06 72 65 6D 6F 74 65 .....!0...remote
> 0050: 1B 15 6C 6F 63 61 6C 68 6F 73 74 2E 6C 6F 63 61 ..localhost.loca
> 0060: 6C 64 6F 6D 61 69 6E A3 81 E3 30 81 E0 A0 03 02 ldomain...0.....
> 0070: 01 11 A2 81 D8 04 81 D5 6B C5 1A F4 8B 3A B3 7B ........k....:..
> 0080: AE 21 B6 7C 76 DA 7F 42 F7 74 77 08 B1 47 5E 91 .!..v..B.tw..G^.
> 0090: 2D 93 54 AA FF 8B A2 A3 F4 ED E4 20 58 8F 1D 3A -.T........ X..:
> 00A0: 11 1D E7 26 86 BF 70 A9 64 F2 D4 B6 E5 5A 7B 6D ...&..p.d....Z.m
> 00B0: D4 4A 47 C3 7E A8 40 8F 6A CE B1 B0 E4 8C 00 CC .JG...@.j.......
> 00C0: AD D0 30 23 D7 A2 6D 55 58 32 9C 0E 4D 48 78 62 ..0#..mUX2..MHxb
> 00D0: 7C BD C5 64 05 A4 2A F1 A7 D9 29 C2 78 F5 A0 E8 ...d..*...).x...
> 00E0: C3 24 77 34 C0 6A 70 27 42 20 47 EA E8 BE 7A 1C .$w4.jp'B G...z.
> 00F0: 72 3A AB 01 E9 5B 71 7A 86 AE E8 D8 00 94 17 2F r:...[qz......./
> 0100: 3F 8F 62 FC 58 4B 27 86 24 78 B9 97 71 1B E4 ED ?.b.XK'.$x..q...
> 0110: 93 A5 8F 1C 1B 7A 31 17 E4 E5 90 2A 02 88 22 39 .....z1....*.."9
> 0120: 9D B9 48 05 89 A2 8D F6 4F E7 29 C6 75 CE 2A EB ..H.....O.).u.*.
> 0130: A4 EB 60 C7 DA 26 AB 75 17 8C 9E 0B 55 A6 69 5B ..`..&.u....U.i[
> 0140: 53 DF 41 F7 E0 48 01 53 44 F3 8A 8F 5A A4 81 E2 S.A..H.SD...Z...
> 0150: 30 81 DF A0 03 02 01 11 A2 81 D7 04 81 D4 F2 C9 0...............
> 0160: 95 00 E1 89 EB 9F AF 03 DB 8E 9C 9B F5 FF E4 AF ................
> 0170: BD AB 4C FA 87 FD 87 B4 0B C8 21 53 7C A2 D9 07 ..L.......!S....
> 0180: 0D 63 D5 EA 76 D4 30 C4 17 ED 1D 90 6B 46 20 BE .c..v.0.....kF .
> 0190: 28 C0 02 87 7D D8 EC 21 0F 50 FC 39 D7 0B AD C3 (......!.P.9....
> 01A0: 07 10 7A F4 79 71 0E 59 5C 8D 55 D6 71 54 4B 35 ..z.yq.Y\.U.qTK5
> 01B0: EE E7 33 87 BD 21 78 79 76 49 DF FA 17 CA 5A B2 ..3..!xyvI....Z.
> 01C0: A6 72 4C 6B E2 CB A6 8F 2E 8B 1B F4 DD 41 4D 85 .rLk.........AM.
> 01D0: 5D 9A 92 5A 90 EB 2F 80 7A 02 F4 05 9A 54 1D D5 ]..Z../.z....T..
> 01E0: 0F 04 12 53 29 1D A1 D3 5B 08 E4 FA 75 F0 AE 2E ...S)...[...u...
> 01F0: F6 07 0E 44 BD F2 6C 0F 3F 95 14 D6 75 2F 12 08 ...D..l.?...u/..
> 0200: 0E F5 6E B9 CB 28 6A 5C 51 7E 4F 9D E0 2F 18 1C ..n..(j\Q.O../..
> 0210: 0D 0D 18 AA 31 FE 8E D2 42 AD CA 62 B1 EF 69 9D ....1...B..b..i.
> 0220: 88 82 57 36 58 B2 72 CF 35 54 B1 BE 9B 57 10 F5 ..W6X.r.5T...W..
> 0230: 2C FF ,.
> Failed to connect to the controller: The controller is not available at localhost.localdomain:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost.localdomain:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost.localdomain:9990. The connection failed: JBREM000202: Abrupt close on Remoting connection 79a3d728 to localhost.localdomain/127.0.0.1:9990 of endpoint "cli-client" <24aed80c>
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2392) Remoting EJB identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2392?page=com.atlassian.jira.plugi... ]
Jan Kalina closed WFCORE-2392.
------------------------------
Resolution: Rejected
Already fixed by other fix, closing.
> Remoting EJB identity propagation does not work with Elytron
> ------------------------------------------------------------
>
> Key: WFCORE-2392
> URL: https://issues.jboss.org/browse/WFCORE-2392
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
> Labels: elytron-legacy-test-fails
> Fix For: 3.0.0.Beta18
>
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8956) MissingMethodPermissionsDefaultAllowedTestCase and MissingMethodPermissionsTestCase fail when run with the Elytron profile enabled
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-8956?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-8956:
-----------------------------
Summary: MissingMethodPermissionsDefaultAllowedTestCase and MissingMethodPermissionsTestCase fail when run with the Elytron profile enabled (was: EJB3 subsystem default security domain is not propagated to secured EJBs without @SecurityDomain annotation if the default security domain is Elytron)
> MissingMethodPermissionsDefaultAllowedTestCase and MissingMethodPermissionsTestCase fail when run with the Elytron profile enabled
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8956
> URL: https://issues.jboss.org/browse/WFLY-8956
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Critical
>
> Suppose a deployment with EJB with security related annotations (for example {{@RolesAllowed}}) but without a {{@SecurityDomain}} annotation. If the EAP running the deployment has attribute {{default-security-domain}} in {{/subsystem=ejb3}} defined, this will be used for any bean without security domain used in deployment. This works with PicketBox domains, however, if an Elytron security domain is defined as default, no such domain will be associated with the deployment.
> This also causes failure of {{org.jboss.as.test.integration.ejb.security.missingmethodpermission.*TestCase}} tests in integration/basic module in test suite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months