October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-699) Client authentication should default to using the URI userInfo if present

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-699?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-699: --------------------------------- Rather than changing the API to require a URI to be given to org.wildfly.security.auth.client.AuthenticationConfiguration#getPrincipal, which would be fairly complex, a better approach might be to modify org.wildfly.security.auth.client.AuthenticationContextConfigurationClient#getAuthenticationConfiguration() to automatically add information from the URI in to the configuration before returning it, like this: * If auth is anonymous, check for userInfo; if present, add it as a setName * If no SetHost*Configuration is set, add the URI host (if any) as setHost * Same for port # Then we can add methods on AuthenticationContextConfigurationClient which do not require a URI to be given, and deprecate those old ones. > Client authentication should default to using the URI userInfo if present > ------------------------------------------------------------------------- > > Key: ELY-699 > URL: https://issues.jboss.org/browse/ELY-699 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > > The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present. The challenge is that the API does not presently require a URI to be given when getting the authentication principal. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-699) Client authentication should default to using the URI userInfo if present

by David Lloyd (JIRA)

David Lloyd created ELY-699: ------------------------------- Summary: Client authentication should default to using the URI userInfo if present Key: ELY-699 URL: https://issues.jboss.org/browse/ELY-699 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present. The challenge is that the API does not presently require a URI to be given when getting the authentication principal. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-119) Where a username and credential are supplied accept the default realm

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-119: --------------------------------------- Summary: Where a username and credential are supplied accept the default realm Key: REMJMX-119 URL: https://issues.jboss.org/browse/REMJMX-119 Project: Remoting JMX Issue Type: Enhancement Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha3 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-698) Rework the constructor exclusion logic for authentication rules and configurations

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-698: --------------------------------- The present requirements for an AuthenticationConfiguration are: * Ordering is insignificant for non-overlapping configurations. For example, if A then B are added into a configuration, and A and B do not logically overlap, the result will be identical to adding B then A. * Equals/hashCode must respect the ordering rule. In the previous example, both configurations must have the same hash code and be equal to one another. * In order to meet this rule, two logically overlapping configurations may not coexist on a configuration. For example, two different configurations that both logically establish a cleartext password will be exclusive, such that whichever one is added last is retained and the other one is dropped. I suppose these rules really should be on the JavaDoc. > Rework the constructor exclusion logic for authentication rules and configurations > ---------------------------------------------------------------------------------- > > Key: ELY-698 > URL: https://issues.jboss.org/browse/ELY-698 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Priority: Minor > > The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist. However the implementation is applied a bit erratically. There may be problems with commutatively applying checks. Some checks may be missing or extraneous. > We need a new approach where the mutual exclusion set is somehow enforced centrally. One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s). A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type. > Another option is to have a marker interface for each capability, and to remove all peers with the same capability. A predicate can also be used in this case. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7410) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-7410: ------------------------------- Description: Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. We also need to handle the case where the response from a node was filtered. > CommandDispatcher.submitOnCluster() futures throw NPEs > ------------------------------------------------------ > > Key: WFLY-7410 > URL: https://issues.jboss.org/browse/WFLY-7410 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. > We also need to handle the case where the response from a node was filtered. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7411) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7411: ---------------------------------- Summary: CommandDispatcher.submitOnCluster() futures throw NPEs Key: WFLY-7411 URL: https://issues.jboss.org/browse/WFLY-7411 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. We also need to handle the case where the response from a node was filtered. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7410) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-7410: ------------------------------- Summary: CommandDispatcher.submitOnCluster() futures throw NPEs (was: CommandDispatcher.submitOnCluster() futures can throw NPEs) > CommandDispatcher.submitOnCluster() futures throw NPEs > ------------------------------------------------------ > > Key: WFLY-7410 > URL: https://issues.jboss.org/browse/WFLY-7410 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7410) CommandDispatcher.submitOnCluster() futures can throw NPEs

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7410: ---------------------------------- Summary: CommandDispatcher.submitOnCluster() futures can throw NPEs Key: WFLY-7410 URL: https://issues.jboss.org/browse/WFLY-7410 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-698) Rework the constructor exclusion logic for authentication rules and configurations

by David Lloyd (JIRA)

David Lloyd created ELY-698: ------------------------------- Summary: Rework the constructor exclusion logic for authentication rules and configurations Key: ELY-698 URL: https://issues.jboss.org/browse/ELY-698 Project: WildFly Elytron Issue Type: Task Components: Authentication Client Reporter: David Lloyd Priority: Minor The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist. However the implementation is applied a bit erratically. There may be problems with commutatively applying checks. Some checks may be missing or extraneous. We need a new approach where the mutual exclusion set is somehow enforced centrally. One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s). A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type. Another option is to have a marker interface for each capability, and to remove all peers with the same capability. A predicate can also be used in this case. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-369) SecurityIdentity-based self-service

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-369?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-369: --------------------------------- For this to work, realms (modifiable or non-modifiable) need to return a modifiable authorization identity which includes credential update methods - _or_ alternatively a modifiable realm needs to return an authorization identity which knows how to re-create the (necessarily modifiable) realm identity to perform the credential update. The latter option is probably better because an AuthorizationIdentity deliberately releases all possible resources; there's no dispose() to call after the change is complete. Therefore if the AuthorizationIdentity gets back the ModifiableRealmIdentity, that realm identity can be used to perform the update and then be disposed (to release the database or LDAP connection for example). Re-finding the RealmIdentity is a non-starter because only the realm can make the guarantee that you are either finding the original identity or that you cannot perform the update. If this guarantee isn't made, there is a risk of updating credentials that the caller does not actually own, which at worst could cause an access breach. > SecurityIdentity-based self-service > ----------------------------------- > > Key: ELY-369 > URL: https://issues.jboss.org/browse/ELY-369 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: David Lloyd > > We may need to provide the ability to allow users to manage their accounts in various ways. > * Password reset -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016