June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1742) Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1742?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1742: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1742 > URL: https://issues.redhat.com/browse/ELY-1742 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 1.13.0.CR1, 2.0.0.Alpha8 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1858) Create Three new shaded jars elytron-common, elytron-acme, and elytron-password

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1858?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1858: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Create Three new shaded jars elytron-common, elytron-acme, and elytron-password > ------------------------------------------------------------------------------- > > Key: ELY-1858 > URL: https://issues.redhat.com/browse/ELY-1858 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha8 > > > These are for use by Quarkus bundling together some of the common dependencies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1888) Review Context Association

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1888?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1888: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Review Context Association > -------------------------- > > Key: ELY-1888 > URL: https://issues.redhat.com/browse/ELY-1888 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, MicroProfile > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 2.0.0.Alpha8 > > > Our APIs are very much written for objects to be associated with the current Thread and to remain associated either until they are replaced or the call stack returns to the point where association occurs and the association is automatically removed. > Concurrent APIs are always a problem in this area as a "request" can now traverse multiple Threads, issues arise in relation to propagation to worker threads but also potentially in the association for any resulting callbacks / resumption of work across different threads. > We should double check our relationship with Jakarta Concurrency: - > https://projects.eclipse.org/projects/ee4j.cu > The following specification within MicroProfile is looking into some mechanisms for this association: - > https://github.com/eclipse/microprofile-context-propagation > It may be preferable for our APIs to remain unchanged but instead we provide sufficient integration to capture our current context specific instances and propagate them. > As we have more than one item that can be associated we may want to review if we want to use a single context internally that associates multiple items so we only have one item to propagate. > Generally the items we associate are immutable so cross Thread modifications are not likely to be an issue. > Alternatively we may choose to revisit our association APIs. > Overall creating this issue for now as it is an area we will need to investigate further and plan for - tentatively scheduled against 2.0 although I suspect we will need to handle this within a 1.x release. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1910) Develop JWT Token Issuer

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1910?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1910: ---------------------------------- Fix Version/s: 2.0.0.Alpha8 (was: 2.0.0.Alpha7) > Develop JWT Token Issuer > ------------------------ > > Key: ELY-1910 > URL: https://issues.redhat.com/browse/ELY-1910 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha8 > > > Assigning to API / SPI for now but we may want to create a new component to track token based authentication, especially JWT. > It may be desirable for us to be able to issue JWT tokens that can be used elsewhere. > At the moment our identity propagation makes use of credentials delegated to us during authentication but we have some more opportunities if we can obtain new credentials dynamically for this propagation. > An ideal use case for this could be a traditional web application already secured using traditional authentication such as username / password via a form, in that case the application will have a resulting SecurityIdentity with attributes, roles, and permissions assigned. > This feature request is to consider a component internal to the process to convert the SecurityIdentity to a JWT token that can now be used for any outbound calls as the identity to propagate the identity. > One possibility is some kind of transformation that can be applied on the SecurityDomain so the resulting SecurityIdentity has an associated JWT token credential as soon as it is created. > Another alternative is more integration within authentication client, the destination could be taken into account so different tokens / mappings are applied for different destinations. > I wont create the separate Jira issue yet but this could also open an option to dynamically obtain a token from a remote issuer - we may have been delegated a credential we can use to authentication against a remote identity provider and request a token that way. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1983) Release WildFly Elytron 2.0.0.Alpha7

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1983?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELY-1983. ----------------------------------- Resolution: Done > Release WildFly Elytron 2.0.0.Alpha7 > ------------------------------------ > > Key: ELY-1983 > URL: https://issues.redhat.com/browse/ELY-1983 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 2.0.0.Alpha7 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1168) Document alternatives for PSI OpenStack

by Matthew Mahoney (Jira)

[ https://issues.redhat.com/browse/SWSQE-1168?page=com.atlassian.jira.plugi... ] Matthew Mahoney commented on SWSQE-1168: ---------------------------------------- Slack OCP Bot: https://app.slack.com/client/T027F3GAJ/D011E5UGDC6 > Document alternatives for PSI OpenStack > --------------------------------------- > > Key: SWSQE-1168 > URL: https://issues.redhat.com/browse/SWSQE-1168 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > When the PSI OpenStack is down, we need to use something else to provisioning OCP clusters. > We need to document options: > * AWS > * https://quicklab.upshift.redhat.com/clusters > * bot on coreos slack -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1168) Document alternatives for PSI OpenStack

by Filip Brychta (Jira)

Filip Brychta created SWSQE-1168: ------------------------------------ Summary: Document alternatives for PSI OpenStack Key: SWSQE-1168 URL: https://issues.redhat.com/browse/SWSQE-1168 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Assignee: Filip Brychta When the PSI OpenStack is down, we need to use something else to provisioning OCP clusters. We need to document options: * AWS * https://quicklab.upshift.redhat.com/clusters * bot on coreos slack -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Alexandru Ciouca (Jira)

[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ] Alexandru Ciouca updated WFLY-13559: ------------------------------------ Attachment: standalone_18.0.0.final.xml standalone_19.1.0.final.xml > Header response has changed and missing fields > ---------------------------------------------- > > Key: WFLY-13559 > URL: https://issues.redhat.com/browse/WFLY-13559 > Project: WildFly > Issue Type: Bug > Affects Versions: 19.1.0.Final > Reporter: Alexandru Ciouca > Assignee: Brian Stansberry > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml > > > I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? > Response WildFly 18.0.0.final: > {code} > HTTP/2 500 > cache-control: no-store, no-cache, must-revalidate > set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices > access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN > content-type: application/json > content-length: 182 > link: <http://test.com/afs/rest>; rel="profile" > date: Thu, 04 Jun 2020 07:34:10 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > Response WildFly 19.1.0.final: > {code} > HTTP/2 200 > set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices > content-type: application/json > content-length: 182 > date: Thu, 04 Jun 2020 07:27:57 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure > cache-control: private > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. > I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1983) Release WildFly Elytron 2.0.0.Alpha7

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1983: ------------------------------------- Summary: Release WildFly Elytron 2.0.0.Alpha7 Key: ELY-1983 URL: https://issues.redhat.com/browse/ELY-1983 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.0.Alpha7 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5372) Investigate PMML abstraction/coexistence

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5372?page=com.atlassian.jira.plug... ] Gabriele Cardosi edited comment on DROOLS-5372 at 6/4/20 10:59 AM: ------------------------------------------------------------------- Most cost-effective solution would be: # create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # inside DMN: ## inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath was (Author: gabriolo): Most cost-effective solution would be: # 1) create a new _Command_ with API tailored for new kie-pmml (see {code:java} ApplyPmmlModelCommand {code} as example) # 2) verify the behavior when *both* {code:java} PMMLAssemblerService {code} s (from old and new kie-pmml) are present in the classpath: ## are both invoked? In such case, use a "_property_" to define which one has to be actually invoked ## only one is invoked ? In such case, evaluate how this may be managed for "openshift/docker" images where both modules are expected to be present in the classpath # 2) inside DMN: ## 1) inside {code:java} AbstractPMMLInvocationEvaluator.PMMLInvocationEvaluatorFactory.newInstance(...) {code} add an "if" to choose wich kie-pmml implementation (old or new) is to be used when the jpmml one is not in the classpath > Investigate PMML abstraction/coexistence > ----------------------------------------- > > Key: DROOLS-5372 > URL: https://issues.redhat.com/browse/DROOLS-5372 > Project: Drools > Issue Type: Task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > New and old PMML implementations should live together for some time. > USer should be able to choose implementation. > Consider creating a "proxy" pmml-module that > 1) declare PMMLAssemblerService > 2) declare PMMLRuntime > 3) delegate actuial executioin based on some variable to actual implementation (ppml-old - pmml-new, jpmml) > This "wrapper" should also be invoked by ApplyPmmlModelCommandExecutorImpl -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 June 2020