October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password Credentials CallbackHandler

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-658: --------------------------- Description: We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type. This should also allow Elytron to support other grant types defined by OAuth2 in the future. Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2]. In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol. [1] https://tools.ietf.org/html/rfc6749#page-9 [2] https://openid.net/specs/openid-connect-discovery-1_0.html was: We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type. This should also allow Elytron to support other grant types defined by OAuth2 in the future. Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2]. In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol. [1] https://tools.ietf.org/html/rfc6749#page-9 [2] https://openid.net/specs/openid-connect-discovery-1_0.html > OAuth2 Resource Owner Password Credentials CallbackHandler > ---------------------------------------------------------- > > Key: ELY-658 > URL: https://issues.jboss.org/browse/ELY-658 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Callbacks > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > > We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{CallbackHandler}} that could be used to handle all the necessary logic related with this grant type. > This should also allow Elytron to support other grant types defined by OAuth2 in the future. > Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2]. > In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol. > [1] https://tools.ietf.org/html/rfc6749#page-9 > [2] https://openid.net/specs/openid-connect-discovery-1_0.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-658) OAuth2 Resource Owner Password Credentials CallbackHandler

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-658?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-658: --------------------------- Summary: OAuth2 Resource Owner Password Credentials CallbackHandler (was: OAuth2 Resource Owner Password Credentials Callback) > OAuth2 Resource Owner Password Credentials CallbackHandler > ---------------------------------------------------------- > > Key: ELY-658 > URL: https://issues.jboss.org/browse/ELY-658 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Callbacks > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > > We must be able to allow OAuth2 SASL clients to obtain tokens on behalf of an user using the Resource Owner Password Credentials Grant Type [1]. To do that we should provide a {{Callback}} that could be used to handle all the necessary logic related with this grant type. > This should also allow Elytron to support other grant types defined by OAuth2 in the future. > Configuration wise, we must be able to obtain the necessary configuration to integrate with an OAuth2/OpenID Connect identity provider. Where this configuration should be purely based on standard options such as those specified by OpenID Connect Discovery [2]. > In fact, maybe we should change our current OAuth2 SASL Client and Servers to refer to OpenID Connect instead. As we are basically addressing authentication and that is what OpenID Connect really provides, differently than OAuth2 that is basically a authorization and delegation protocol. > [1] https://tools.ietf.org/html/rfc6749#page-9 > [2] https://openid.net/specs/openid-connect-discovery-1_0.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-773) ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-773?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-773: ----------------------------------------- The linked PR fixing changes the management API description of the threads and jca subsystems. That's ok to do in a community major/EAP minor. We should bump the management API versions if the version has not been bumped already, but TBH I don't care that much. We don't actually use subsystem=threads any more. > ArrayIndexOutOfBoundsException occurs when a queue-length is 0 in the thread pool executor > -------------------------------------------------------------------------------------------- > > Key: WFCORE-773 > URL: https://issues.jboss.org/browse/WFCORE-773 > Project: WildFly Core > Issue Type: Bug > Reporter: Enrique González Martínez > Assignee: Petr Jurak > > BoundedQueueThreadPool does not support zero length queue setup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final deployment crash

by Michael Peoples (JIRA)

[ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.... ] Michael Peoples commented on WFLY-6500: --------------------------------------- I've no idea because we use a distribution of WildFly that is packaged with the Camunda distribution. That said, there's probably nothing stopping us from using a separate WildFly distribution other than dependencies that Camunda resolves for us in the distribution package. I don't know if they're planning to bump the version. > wildfly-10.0.0.Final deployment crash > ------------------------------------- > > Key: WFLY-6500 > URL: https://issues.jboss.org/browse/WFLY-6500 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Jason Morgan > Assignee: Jason Greene > > Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final deployment crash

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6500: ----------------------------------- Does this still happen on 10.1.0? As there was quite some fixes in this area > wildfly-10.0.0.Final deployment crash > ------------------------------------- > > Key: WFLY-6500 > URL: https://issues.jboss.org/browse/WFLY-6500 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Jason Morgan > Assignee: Jason Greene > > Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6500) wildfly-10.0.0.Final deployment crash

by Michael Peoples (JIRA)

[ https://issues.jboss.org/browse/WFLY-6500?page=com.atlassian.jira.plugin.... ] Michael Peoples commented on WFLY-6500: --------------------------------------- We are experiencing similar behavior using WildFly 10.0.0 with Camunda BPM 7.5.3-ee. I wish I could help with this, but I think the only resolution is to deploy using only one method and don't mix deployments place manually in the deployment directory with those deployed through the console GUI, command line interface, or management API interface. > wildfly-10.0.0.Final deployment crash > ------------------------------------- > > Key: WFLY-6500 > URL: https://issues.jboss.org/browse/WFLY-6500 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Jason Morgan > Assignee: Jason Greene > > Having a war in the deployment directory and then "replacing" a deployment through the web console causes the server to crash without any logging on restart -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1884) Introduce discovery subsystem

by David Lloyd (JIRA)

David Lloyd created WFCORE-1884: ----------------------------------- Summary: Introduce discovery subsystem Key: WFCORE-1884 URL: https://issues.jboss.org/browse/WFCORE-1884 Project: WildFly Core Issue Type: Enhancement Reporter: David Lloyd Assignee: David Lloyd Fix For: 3.0.0.Alpha10 Introduce discovery subsystem to be used by any other subsystem which can utilize discovery. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7351?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-7351: --------------------------------- Assignee: Alessio Soldano (was: Stuart Douglas) Could be that this is fixed in resteasy 3.1, but we need to check anyway. > JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-7351 > URL: https://issues.jboss.org/browse/WFLY-7351 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.1.0.Final > Environment: N/A > Reporter: Edvin Syse > Assignee: Alessio Soldano > Labels: httpclient, https, jax-rs > Attachments: httpclient-sni-bug.zip > > > When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails. > When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered. > Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error). > This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days. > The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7351) JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it

by Edvin Syse (JIRA)

Edvin Syse created WFLY-7351: -------------------------------- Summary: JAX-RS Http Client does not support SNI even though underlying Apache HttpClient version supports it Key: WFLY-7351 URL: https://issues.jboss.org/browse/WFLY-7351 Project: WildFly Issue Type: Bug Components: REST Affects Versions: 10.1.0.Final Environment: N/A Reporter: Edvin Syse Assignee: Stuart Douglas Attachments: httpclient-sni-bug.zip When creating a JAX-RS client using ClientBuilder.newClient() and accessing an SSL resource configured with SNI, the request fails. When the request is made you get the default certificate for the ip as it is configured on the web server instead of the certificate corresponding to the host name you entered. Attached is a simple Maven project with a rest endpoint that will make a request to https://www.syse.no/, which is a host configured with SNI. If you access this host with a client that is not SNI capable, you will get the default certificate instead of the one corresponding to www.syse.no. (That cert is actually expired, so that is the underlying cause reported by the http client in this case. In other cases you will most probably just get a name mismatch type of error). This effectively prevents the Http client from being used reliably against a rapidly growing number of SSL enabled sites, as SNI is the new standard "everywhere" SSL is configured these days. The underlying Apache HttpClient version does indeed support SNI. I have tested the version of Apache HttpClient that is bundled with Wildfly 10.1 and it works correctly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7350) Frequent intermittent failures in coarse/fine web session passivation tests

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7350: ---------------------------------- Summary: Frequent intermittent failures in coarse/fine web session passivation tests Key: WFLY-7350 URL: https://issues.jboss.org/browse/WFLY-7350 Project: WildFly Issue Type: Bug Components: Clustering, Test Suite Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016