August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-157) [QE] - JMAN4-203 - Fuse integration - add Fuse server entity representation in MIQ

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-157?page=com.atlassian.jira.pl... ] Hayk Hovsepyan updated HAWKULARQE-157: -------------------------------------- Description: See [JMAN4-203|https://issues.jboss.org/browse/JMAN4-203] Test Plan document: https://mojo.redhat.com/docs/DOC-1146423 was:See [JMAN4-203|https://issues.jboss.org/browse/JMAN4-203] > [QE] - JMAN4-203 - Fuse integration - add Fuse server entity representation in MIQ > ---------------------------------------------------------------------------------- > > Key: HAWKULARQE-157 > URL: https://issues.jboss.org/browse/HAWKULARQE-157 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Labels: 5.0, mm-integration-hawkular-qe > > See [JMAN4-203|https://issues.jboss.org/browse/JMAN4-203] > Test Plan document: https://mojo.redhat.com/docs/DOC-1146423 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-166) [QE] - JMAN4-206 - Fuse integration - support operations on entities in MIQ

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-166?page=com.atlassian.jira.pl... ] Hayk Hovsepyan updated HAWKULARQE-166: -------------------------------------- Description: See [JMAN4-206|https://issues.jboss.org/browse/JMAN4-206] (was: See [JMAN4-203|https://issues.jboss.org/browse/JMAN4-203]) > [QE] - JMAN4-206 - Fuse integration - support operations on entities in MIQ > --------------------------------------------------------------------------- > > Key: HAWKULARQE-166 > URL: https://issues.jboss.org/browse/HAWKULARQE-166 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Labels: 5.0, mm-integration-hawkular-qe > > See [JMAN4-206|https://issues.jboss.org/browse/JMAN4-206] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-163) [QE] - JMAN4-205 - Fuse integration - collect metrics for the supported entities

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-163?page=com.atlassian.jira.pl... ] Hayk Hovsepyan updated HAWKULARQE-163: -------------------------------------- Description: See https://issues.jboss.org/browse/JMAN4-205 > [QE] - JMAN4-205 - Fuse integration - collect metrics for the supported entities > -------------------------------------------------------------------------------- > > Key: HAWKULARQE-163 > URL: https://issues.jboss.org/browse/HAWKULARQE-163 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Michael Foley > Labels: 5.0, mm-integration-hawkular-qe > > See https://issues.jboss.org/browse/JMAN4-205 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3180) ElytronSubsystemMessages uses double quotes to surround string literals

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3180: ---------------------------------------- Summary: ElytronSubsystemMessages uses double quotes to surround string literals Key: WFCORE-3180 URL: https://issues.jboss.org/browse/WFCORE-3180 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Brian Stansberry Assignee: Darran Lofthouse Priority: Minor Lots of things like this: @Message(id = 910, value = "Password cannot be resolved for key-store \"%s\"") Use ' instead of \". If the string ends up in a DMR ModelNode, which it often does, the output looks bad when double quotes are present. For this ModelNode ModelNode node = new ModelNode("Password cannot be resolved for key-store \"%s\""); A call to node.toString() produces "Password cannot be resolved for key-store \"%s\"" node.asString() is better, but that requires a special call vs the standard Object.toString Password cannot be resolved for key-store "%s" This is minor since we can try to ensure asString is used or perhaps even consider changing how toString works. But I think single quotes are a better practice. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3179) Add Elytron Kerberos tests for native management interface

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3179?page=com.atlassian.jira.plugi... ] Josef Cacek moved WFLY-8995 to WFCORE-3179: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-3179 (was: WFLY-8995) Component/s: Test Suite (was: Test Suite) > Add Elytron Kerberos tests for native management interface > ---------------------------------------------------------- > > Key: WFCORE-3179 > URL: https://issues.jboss.org/browse/WFCORE-3179 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Critical > > Add Kerberos SASL mechanisms (GSSAPI, GS2-KRB5*) tests into AS TS. > This is follow-up task for JBEAP-11194/WFCORE-2881. As the ApacheDS is only used in the TS of full WildFly, the new tests won't be placed into core, but into full ({{testsuite/integration/elytron}}). > This task relates to RFE EAP7-142. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1330) Elytron GS2-KRB5 SASL mechanism (non-PLUS) is allowed even if the channel binding is possible

by Josef Cacek (JIRA)

Josef Cacek created ELY-1330: -------------------------------- Summary: Elytron GS2-KRB5 SASL mechanism (non-PLUS) is allowed even if the channel binding is possible Key: ELY-1330 URL: https://issues.jboss.org/browse/ELY-1330 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker Using GS2-KRB5-PLUS mechanism should be forced when channel binding is possible (server-ssl-context is used) and GS2-KRB5 should not be allowed in such case. Currently the GS2-KRB5 authentication passes even if the SSL server context is used (channel binding possible). This is a follow up to JBEAP-11396 and JBEAP-12231 which were aimed on SCRAM PLUS mechanisms. Most of the related discussion takes place on JBEAP-11396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-975) Default distinguishedNameAttribute value of LdapExtLoginModule causes not working referrals on MS Active Directory

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-975?page=com.atlassian.jira.plug... ] Jiri Ondrusek updated SECURITY-975: ----------------------------------- Git Pull Request: https://github.com/picketbox/picketbox/pull/70 > Default distinguishedNameAttribute value of LdapExtLoginModule causes not working referrals on MS Active Directory > ------------------------------------------------------------------------------------------------------------------ > > Key: SECURITY-975 > URL: https://issues.jboss.org/browse/SECURITY-975 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_5_0_2.Final > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In case when crossRef object to different domain is configured on MS Active Directory for handling referrals and JBoss EAP 7 uses LdapExtLoginModule then default value ('distinguishedName') of distinguishedNameAttribute option causes wrong handling of referrals which leads to authentication fail for referral users. > Referral object is returned by original LDAP server (LDAP server which includes crossRef to different domain) but user is obtained through value of distinguishedName attribute from that response. It leads to authentication attempt with referral user against original LDAP server instead of referenced LDAP server which results to failed authentication. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1329) FormAuthenticationMechanism must cope with a null scope.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1329: ------------------------------------- Summary: FormAuthenticationMechanism must cope with a null scope. Key: ELY-1329 URL: https://issues.jboss.org/browse/ELY-1329 Project: WildFly Elytron Issue Type: Bug Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 1.1.0.CR6 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-5932. ------------------------------ Fix Version/s: 11.0.0.Beta1 (was: 10.1.0.CR1) (was: 10.1.0.Final) Resolution: Done > Invalidating a session of an SSO on a different node than where the session was created does not logout the user > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5932 > URL: https://issues.jboss.org/browse/WFLY-5932 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR5 > Reporter: Richard Janík > Assignee: Paul Ferraro > Priority: Blocker > Fix For: 11.0.0.Beta1 > > > See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate): > * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2 > Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected): > * Access A1, authenticate, invalidate session on A1, access A1 > * Access A1, authenticate, access A2, invalidate session on A1, access A1 > Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1328) Unable to use GS2-KRB5-PLUS SASL mechanism - AP_REQ token id does not match

by Josef Cacek (JIRA)

[ https://issues.jboss.org/browse/ELY-1328?page=com.atlassian.jira.plugin.s... ] Josef Cacek updated ELY-1328: ----------------------------- Description: Invalid initial token is used on server for *GS2-KRB5-PLUS* SASL mechanism. The {{Gs2SaslServer}} uses a GSSContext to accept the token. It expects AP_REQ is comming (*{{AP_REQ_ID=256}}*), but the incomming tokenId has value *{{669}}* (value of first 2 bytes of token body). Setting blocker as this mechanism is required by EAP7-530 and EAP7-142. Following exception is thrown: {noformat} GSSException: Defective token detected (Mechanism level: AP_REQ token id does not match!) at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:96) at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) at org.wildfly.security.sasl.gs2.Gs2SaslServer.evaluateMessage(Gs2SaslServer.java:212) at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180) at org.wildfly.security.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:52) 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:486) at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898) 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:748) {noformat} was: Invalid initial token is used on server for *GS2-KRB5-PLUS* SASL mechanism. The {{Gs2SaslServer}} uses a GSSContext to accept the token. It expects AP_REQ is comming (*{{AP_REQ_ID=256}}*), but the incomming tokenId has value *{{669}}* (value of first 2 bytes of token body). Setting blocker as this mechanism is required by EAP7-530. Following exception is thrown: {noformat} GSSException: Defective token detected (Mechanism level: AP_REQ token id does not match!) at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:96) at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342) at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) at org.wildfly.security.sasl.gs2.Gs2SaslServer.evaluateMessage(Gs2SaslServer.java:212) at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180) at org.wildfly.security.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:52) 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:486) at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898) 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:748) {noformat} > Unable to use GS2-KRB5-PLUS SASL mechanism - AP_REQ token id does not match > --------------------------------------------------------------------------- > > Key: ELY-1328 > URL: https://issues.jboss.org/browse/ELY-1328 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > > Invalid initial token is used on server for *GS2-KRB5-PLUS* SASL mechanism. The {{Gs2SaslServer}} uses a GSSContext to accept the token. It expects AP_REQ is comming (*{{AP_REQ_ID=256}}*), but the incomming tokenId has value *{{669}}* (value of first 2 bytes of token body). > Setting blocker as this mechanism is required by EAP7-530 and EAP7-142. > Following exception is thrown: > {noformat} > GSSException: Defective token detected (Mechanism level: AP_REQ token id does not match!) > at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:96) > at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829) > at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342) > at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285) > at org.wildfly.security.sasl.gs2.Gs2SaslServer.evaluateMessage(Gs2SaslServer.java:212) > at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:180) > at org.wildfly.security.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:52) > 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:486) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:898) > 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:748) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017