September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-281) Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-281?page=com.atlassian.jira.plugin.sy... ] Farah Juma commented on ELY-281: -------------------------------- *OTP credential updates* For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. Note that the OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though). *How OTP credential updates are currently handled* PR [#277|https://github.com/wildfly-security/wildfly-elytron/pull/277] adds handling for {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}, as shown below. This is used for both the OTP sequence reset case as well as the non-reset case. https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/java/org/... *Using the credential verification API instead* An alternative option is to pass the guess that's being verified to the realm and have the realm update the stored credential if verification succeeds. I've got an initial implementation of this approach here (see the three latest commits): https://github.com/fjuma/wildfly-elytron/commits/ELY-281 However, there are a couple of issues with this approach: 1. The [OTP sequence reset case|https://github.com/fjuma/wildfly-elytron/blob/ELY-281/src/main/java/...] still needs to be handled by {{ServerAuthenticationContext}} via {{CredentialUpdateCallback}}. This might be ok though since other mechanisms may also need to support password resets. 2. This approach relies on {{PasswordFactory#verify}} being called from {{ModifiableRealmIdentity#verifyCredential}}. Once PR [#271|https://github.com/wildfly-security/wildfly-elytron/pull/271] is merged, support for OTP passwords will also be available in the LDAP realm. However, {{LdapRealmIdentity#verifyCredential}} does not call {{PasswordFactory#verify}} so it's not clear yet how OTP credential verification and updates would be handled in cases like this with this approach. > Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-281 > URL: https://issues.jboss.org/browse/ELY-281 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Farah Juma > Assignee: Farah Juma > > The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds. > Relevant chat discussion: > {quote} > \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm > \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update > \[8:43 AM\] Kabir Khan: That is what I had planned > \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally > \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible > \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though > \[8:44 AM\] Kabir Khan: the first option is what stood out to me > \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext > {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5257) Unix Domain Socket Listener to Undertow

by Marcio Ricardo Hatzlhoffer Correia (JIRA)

Marcio Ricardo Hatzlhoffer Correia created WFLY-5257: -------------------------------------------------------- Summary: Unix Domain Socket Listener to Undertow Key: WFLY-5257 URL: https://issues.jboss.org/browse/WFLY-5257 Project: WildFly Issue Type: Feature Request Components: IO Environment: Unix/Linux Reporter: Marcio Ricardo Hatzlhoffer Correia Assignee: Jason Greene For many cases, it's used an application like Apache or Nginx as a Reverse Proxy in front of Wildfly. As there is no option to use Unix Domain Socket, these applications use the TCP stack to redirect the connection to the Wildfly (Undertow) and it incurs a slight performance overhead. In the case of a Reverse Proxy configuration where your upstream server is on the same machine, you can get better performance by skipping the TCP/Network stack and using Unix Domain Sockets. A Unix Domain Socket is communication mechanism to do inter-process messaging within the operating system kernel, using the file system as the name space. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1958) RequestCorrelator "channel is not connected" error during shutdown

by Dennis Reed (JIRA)

Dennis Reed created JGRP-1958: --------------------------------- Summary: RequestCorrelator "channel is not connected" error during shutdown Key: JGRP-1958 URL: https://issues.jboss.org/browse/JGRP-1958 Project: JGroups Issue Type: Bug Affects Versions: 3.2.12 Reporter: Dennis Reed Assignee: Bela Ban Priority: Minor Error logged during shutdown of a channel due to RequestCorrelator failing to send a reply: ERROR [org.jgroups.protocols.UNICAST2] (OOB-17,shared=tcp) couldn't deliver OOB message [dst: server1/web, src: server2/web (4 headers), size=62 bytes, flags=OOB|DONT_BUNDLE|RSVP]: java.lang.IllegalStateException: channel is not connected at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:617) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:544) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:391) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:249) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:600) [jgroups-3.2.12.Final-redhat-1.jar:3.2.12.Final-redhat-1] [incoming JGroups message] It appears to just be a timing issue between shutdown of the channel and RequestCorrelator processing the message, which triggers a response message. It would be good to either avoid triggering the exception in the first place, or suppress the error log during shutdown. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-943) Add missing remoting transformers for EAP 6.4.0 (ModelVersion 1.4.0)

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-943: --------------------------------- Summary: Add missing remoting transformers for EAP 6.4.0 (ModelVersion 1.4.0) Key: WFCORE-943 URL: https://issues.jboss.org/browse/WFCORE-943 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Affects Versions: 2.0.0.Beta5 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 2.0.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-281) Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API

by Farah Juma (JIRA)

Farah Juma created ELY-281: ------------------------------ Summary: Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API Key: ELY-281 URL: https://issues.jboss.org/browse/ELY-281 Project: WildFly Elytron Issue Type: Feature Request Components: SASL Reporter: Farah Juma Assignee: Farah Juma The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds. Relevant chat discussion: {quote} \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update \[8:43 AM\] Kabir Khan: That is what I had planned \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though \[8:44 AM\] Kabir Khan: the first option is what stood out to me \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext {quote} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5256) HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED

by Manuel Colchete (JIRA)

[ https://issues.jboss.org/browse/WFLY-5256?page=com.atlassian.jira.plugin.... ] Manuel Colchete updated WFLY-5256: ---------------------------------- Affects Version/s: 8.2.0.Final (was: 8.0.0.CR1) > HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED > -------------------------------------------------------------------------------------- > > Key: WFLY-5256 > URL: https://issues.jboss.org/browse/WFLY-5256 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Reporter: Manuel Colchete > Assignee: Stuart Douglas > Priority: Minor > Fix For: 8.0.0.Final > > > HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-942) Parameter completion for :read-resource and :read-children-resources is broken

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-942: --------------------------------------- Summary: Parameter completion for :read-resource and :read-children-resources is broken Key: WFCORE-942 URL: https://issues.jboss.org/browse/WFCORE-942 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 2.0.0.Beta5 Reporter: Brian Stansberry Assignee: Alexey Loubyansky Priority: Critical Fix For: 2.0.0.CR1 When I try to use tab completion to add parameters to "read-resource" and "read-children-resources" operations, it does not suggest any params but instead just closes the parameter list. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5256) HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED

by Manuel Colchete (JIRA)

Manuel Colchete created WFLY-5256: ------------------------------------- Summary: HTTPS undertow listener request client certificate despite verify-client=NOT_REQUESTED Key: WFLY-5256 URL: https://issues.jboss.org/browse/WFLY-5256 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 8.0.0.CR1 Reporter: Manuel Colchete Assignee: Stuart Douglas Priority: Minor Fix For: 8.0.0.Final HTTPS undertow listener has 3 options for verify-client parameter: NOT_REQUESTED (Default), REQUESTED, REQUIRED. If it is set to NOT_REQUESTED (the default), it should not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. But when I tried to access unsecured resource as first, it requested certificate. (It behaves same as verify-client is set to REQUESTED) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5249) wildfly-hibernate3 quickstart fails to validate in eclipse

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/WFLY-5249?page=com.atlassian.jira.plugin.... ] Rob Stryker reopened WFLY-5249: ------------------------------- there are still users of wf9 who check out the 9.x branch of this repository to engage in quickstarts. Shouldn't this be fixed in the 9.x branch at least, so that users who check out 9.x of quickstarts can import without error? > wildfly-hibernate3 quickstart fails to validate in eclipse > ---------------------------------------------------------- > > Key: WFLY-5249 > URL: https://issues.jboss.org/browse/WFLY-5249 > Project: WildFly > Issue Type: Bug > Reporter: Rob Stryker > Assignee: Jason Greene > > wildfly-hibernate3 quickstart has xml file with following content: > {code} > <persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" > version="2.0"> > {code} > This fails because it is importing the persistence_2_1.xsd file, but is setting version=2.0. It must set version=2.1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5255) EJB3 needs transformers for EAP 6.4.0

by Kabir Khan (JIRA)

Kabir Khan created WFLY-5255: -------------------------------- Summary: EJB3 needs transformers for EAP 6.4.0 Key: WFLY-5255 URL: https://issues.jboss.org/browse/WFLY-5255 Project: WildFly Issue Type: Feature Request Components: Domain Management Affects Versions: 10.0.0.Beta2 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 10.0.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2015