July 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1597) Identity Restoration where the Principal is not quite enough.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1597?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1597: ---------------------------------- Fix Version/s: 1.5.2.CR1 (was: 1.5.1.Final) > Identity Restoration where the Principal is not quite enough. > ------------------------------------------------------------- > > Key: ELY-1597 > URL: https://issues.jboss.org/browse/ELY-1597 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.5.2.CR1 > > > Presently our authentication process is build around a SecurityRealm being able to create a RealmIdentity which we then convert to an AuthorizationIdentity which is then converted to a SecurityIdentity after applying appropriate SecurityDomain configured mappings. > Generally in a SecurityRealm one of two different methods tend to be used to create the RealmIdentity. > {code:java} > RealmIdentity getRealmIdentity(Principal principal) throws RealmUnavailableException > {code} > or > {code:java} > RealmIdentity getRealmIdentity(Evidence evidence) throws RealmUnavailableException > {code} > Generally from the realms we know about, where the Principal form of the method is used the realm will likely load the attributes that go into the AuthorizationIdentity from another source, however for the form that takes Evidence often the attributes can be derived from the evidence. > Where we persist identities to be restored later such as identity propagation, batch, clustering etc we persist the name of the identity and use it to restore the identity using the Principal form of the above methods. For cases where an identity was originally created using evidence we no longer have sufficient information to recreate the identity. > This Enhancement is to review how we can address this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1504) Support Elytron specific callbacks with JASPIC ServerAuthenticationModules

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1504?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1504: ---------------------------------- Fix Version/s: 1.5.2.CR1 (was: 1.5.1.Final) > Support Elytron specific callbacks with JASPIC ServerAuthenticationModules > -------------------------------------------------------------------------- > > Key: ELY-1504 > URL: https://issues.jboss.org/browse/ELY-1504 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.2.CR1 > > > JASPIC already supports the use of a CallbackHandler for communication between the ServerAuthenticationModule and the container the first stage of implementation is to support the callbacks mandated by the spec - this task is to follow up and add support for Elytron specific callbacks. > The reason to split this out is we may still want to handle our core lifecycle related callbacks so of the remaining callbacks we will need to decide which ones we want to support. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1619) Release WildFly Elytron 1.5.1.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1619?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1619. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.5.1.Final > ----------------------------------- > > Key: ELY-1619 > URL: https://issues.jboss.org/browse/ELY-1619 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.1.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3986) Upgrade WildFly Elytron to 1.5.1.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-3986: ---------------------------------------- Summary: Upgrade WildFly Elytron to 1.5.1.Final Key: WFCORE-3986 URL: https://issues.jboss.org/browse/WFCORE-3986 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 6.0.0.Alpha5 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1619) Release WildFly Elytron 1.5.1.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1619: ------------------------------------- Summary: Release WildFly Elytron 1.5.1.Final Key: ELY-1619 URL: https://issues.jboss.org/browse/ELY-1619 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.5.1.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-2787: --------------------------------------- [~uxdlc] that sounds correct to me. Later, we will need to be able to define "restrictions" on types, but for now, the above is great. > "Data Type" tree-grid table interactions. > ----------------------------------------- > > Key: DROOLS-2787 > URL: https://issues.jboss.org/browse/DROOLS-2787 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam, drools-tools > Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, add_basic.png, treegrid.png, type_definitions.pdf > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases: > As a user I want to: > * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.) > * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.) > * *Remove* Data Types from the list of available selections. > * be prevented from making selections that are not valid or would cause an error. > * know that when I edit a data type the changes will be updated in the DMN model. > Functional considerations/ pre conditions: > * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same. > * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-2787: ------------------------------------- [~tirelli] [~manstis] [~karreiro] I'm documenting the info gleaned from the call today: 1. Modal dialog options need to cover the following cases: Select only a "default" type (no need to name the data type because it's a default type.) # The requires only a selection mechanism for selecting a "default" type. 2. Create a custom type - provide a "custom" name and select either a default type or a pre-existing custom type. 3. This requires an input field for providing a custom name and a means to select from one of two types: existing custom or default. * Create a structured type - type with children types, the whole works plus nested. In addition to the use cases above, preference/requirement for the design offering the following: * All types available through modal dialog (including simple default type.) * Tree or tree/table to represent nested hierarchy within Structured type. * Inline editing where possible. If I didn't capture this correctly please let me know, thanks. I plan to do A/B click-thru - one example using the tree-table, one without basically. > "Data Type" tree-grid table interactions. > ----------------------------------------- > > Key: DROOLS-2787 > URL: https://issues.jboss.org/browse/DROOLS-2787 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam, drools-tools > Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, Screen Shot 2018-07-27 at 11.48.34 AM.png, Screen Shot 2018-07-27 at 12.24.49 PM.png, Screen Shot 2018-07-27 at 12.27.13 PM.png, add_basic.png, treegrid.png, type_definitions.pdf > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases: > As a user I want to: > * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.) > * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.) > * *Remove* Data Types from the list of available selections. > * be prevented from making selections that are not valid or would cause an error. > * know that when I edit a data type the changes will be updated in the DMN model. > Functional considerations/ pre conditions: > * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same. > * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3982) Update Capability ServiceTarget/Builder to use the new Service API.

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3982?page=com.atlassian.jira.plugi... ] Richard Opalka commented on WFCORE-3982: ---------------------------------------- Yes, this is one of missing API bits in WFLY [~jmesnil]. > Update Capability ServiceTarget/Builder to use the new Service API. > ------------------------------------------------------------------- > > Key: WFCORE-3982 > URL: https://issues.jboss.org/browse/WFCORE-3982 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 6.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Capabilities provided by service are installed with org.jboss.as.controller.CapabilityServiceTarget#addCapability that uses the deprecated org.jboss.msc.service.Service API. > It is not possible to provide a capability provided by the new org.jboss.msc.Service API. > In particular, there is a chicken and egg issue between org.jboss.as.controller.CapabilityServiceTarget#addCapability that needs an instance of the service(and returns a CapabilityServiceBuilder) and org.jboss.msc.service.ServiceBuilder#provides that creates a Consumer instance to pass to the service instance before this one is set with org.jboss.msc.service.ServiceBuilder#setInstance. > new workflow should be: > {code} > CapabilityServiceBuilder serviceBuilder = context.getCapabilityServiceTarget().addCapability(CAP_NAME); > Consumer<MyValue> consumer = serviceBuilder.provides(CAP_NAME); > Service myService = new MyService(consumer); > serviceBuilder.setInstance(myService) > .install(); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10735) Unable to disable iiop port (non-ssl)

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10735?page=com.atlassian.jira.plugin... ] Tomasz Adamski edited comment on WFLY-10735 at 7/31/18 12:02 PM: ----------------------------------------------------------------- This issue has to wait till WFLY-9107 is merged. I have to provide one fix after it is merged. was (Author: tomekadamski): This issue was fixed and is working correctly in WF14. > Unable to disable iiop port (non-ssl) > ------------------------------------- > > Key: WFLY-10735 > URL: https://issues.jboss.org/browse/WFLY-10735 > Project: WildFly > Issue Type: Bug > Affects Versions: 13.0.0.Final > Reporter: Derek Horton > Assignee: Tomasz Adamski > Fix For: 14.0.0.CR1 > > > Wildfly 13.0.0.Final > Removing the "iiop" socket-binding from the orb configuration: > <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.0"> > <orb ssl-socket-binding="iiop-ssl"/> > <initializers security="identity" transactions="spec"/> > <security server-requires-ssl="true" client-requires-ssl="true" support-ssl="true" security-domain="jsse"/> > </subsystem> > and commenting out the iiop socket-binding leads to the following error: > 2018-07-24 14:47:29,315 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.binding.iiop"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.iiop-openjdk.orb-service is missing [jboss.binding.iiop]"] > } > 2018-07-24 14:47:29,351 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.binding.iiop (missing) dependents: [service jboss.iiop-openjdk.orb-service] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10735) Unable to disable iiop port (non-ssl)

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-10735?page=com.atlassian.jira.plugin... ] Tomasz Adamski reopened WFLY-10735: ----------------------------------- > Unable to disable iiop port (non-ssl) > ------------------------------------- > > Key: WFLY-10735 > URL: https://issues.jboss.org/browse/WFLY-10735 > Project: WildFly > Issue Type: Bug > Affects Versions: 13.0.0.Final > Reporter: Derek Horton > Assignee: Tomasz Adamski > Fix For: 14.0.0.CR1 > > > Wildfly 13.0.0.Final > Removing the "iiop" socket-binding from the orb configuration: > <subsystem xmlns="urn:jboss:domain:iiop-openjdk:2.0"> > <orb ssl-socket-binding="iiop-ssl"/> > <initializers security="identity" transactions="spec"/> > <security server-requires-ssl="true" client-requires-ssl="true" support-ssl="true" security-domain="jsse"/> > </subsystem> > and commenting out the iiop socket-binding leads to the following error: > 2018-07-24 14:47:29,315 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "iiop-openjdk")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.binding.iiop"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.iiop-openjdk.orb-service is missing [jboss.binding.iiop]"] > } > 2018-07-24 14:47:29,351 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.binding.iiop (missing) dependents: [service jboss.iiop-openjdk.orb-service] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 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 July 2018