March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-524: --------------------------- Fix Version/s: 1.1.0.Beta28 (was: 1.1.0.Beta32) > RealmIdentity data caching support in the LDAP realm > ---------------------------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta28 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ] Pedro Igor reassigned ELY-524: ------------------------------ Assignee: Jan Kalina (was: Pedro Igor) > RealmIdentity data caching support in the LDAP realm > ---------------------------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta28 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-524: -------------------------------- Already ensured by caching realm. > RealmIdentity data caching support in the LDAP realm > ---------------------------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta32 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2463) Configuring more password types should be allowed for Elytron filesystem-realm identity in management model

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2463?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2463: ------------------------------------- Fix Version/s: 3.0.0.Beta9 > Configuring more password types should be allowed for Elytron filesystem-realm identity in management model > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2463 > URL: https://issues.jboss.org/browse/WFCORE-2463 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Pedro Igor > Labels: user_experience > Fix For: 3.0.0.Beta9 > > > In case when two password type are part of {{set-password}} operation for identity of Elytron filesystem-realm then only first of them is used and others are discarded. Configuring multiple credentials for one identity should be supported [1]. > [1] https://issues.jboss.org/browse/WFLY-7584?focusedCommentId=13322919&page=... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2393) Elytron expects certificate in PEM format as user input

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2393?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2393: ------------------------------------- Fix Version/s: 3.0.0.Beta9 > Elytron expects certificate in PEM format as user input > ------------------------------------------------------- > > Key: WFCORE-2393 > URL: https://issues.jboss.org/browse/WFCORE-2393 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Labels: user_experience > Fix For: 3.0.0.Beta9 > > > In {{/token-realm/public-key}} attribute there is certificate in PEM format expected, which I consider to be user un-friendly. > I wonder couldn't that be accomplished by leveraging key-store/trust-manager capability? > {code} > "public-key" => { > "type" => STRING, > "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.", > "expressions-allowed" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2364) User should be able to specify only one password mapper in jdbc-realm resource

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2364?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2364: ------------------------------------- Fix Version/s: 3.0.0.Beta9 > User should be able to specify only one password mapper in jdbc-realm resource > ------------------------------------------------------------------------------ > > Key: WFCORE-2364 > URL: https://issues.jboss.org/browse/WFCORE-2364 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Martin Choma > Assignee: Pedro Igor > Priority: Minor > Labels: user_experience > Fix For: 3.0.0.Beta9 > > > It is possible to specify in {{principal-query}} all of {{clear-password-mapper}}, {{bcrypt-mapper}}, {{simple-digest-mapper}}, {{salted-simple-digest-mapper}}, {{scram-mapper}} at one moment. But, in fact, specifying only one mapper per principal query make sense. Change model/subsystem , that only adding on password mapper at a moment is allowed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8125) Programatically set Elytron AuthenticationContext does not work in application server modules

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-8125?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-8125: --------------------------------- Assignee: David Lloyd (was: Darran Lofthouse) > Programatically set Elytron AuthenticationContext does not work in application server modules > --------------------------------------------------------------------------------------------- > > Key: WFLY-8125 > URL: https://issues.jboss.org/browse/WFLY-8125 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: David Lloyd > Priority: Blocker > Attachments: module-without-wildfly-config-xml-dep.war, module-without-wildfly-config-xml.jar > > > In case when code inside of any module in aplication server executes management operation through programatically configured AuthenticationContext then it is not work correctly. > According to server log it seems that for some reason it at the first authenticate correctly through programatically configured AuthenticationContext, but then it try to reauthenticate through AuthenticationContext obtained from application server (if default-authentication-context is set then it is used; otherwise reauthenticate fails completetly). > The same type of behavior occurs also when {{wildfly.config.url}} property is used. > Request blocker flag because this issue breaks RFE. > Server log (when default-authentication-context is set, see Steps to Reproduce): > {code} > 2017-02-15 13:43:30,584 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990] > 2017-02-15 13:43:30,585 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user2,Credentials,realm=ManagementRealm,host=localhost,port=9990] > 2017-02-15 13:43:30,596 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback > 2017-02-15 13:43:30,597 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback > 2017-02-15 13:43:30,598 TRACE [org.wildfly.security] (management I/O-2) Handling AvailableRealmsCallback: realms = [ManagementRealm] > 2017-02-15 13:43:30,607 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ManagementRealm] > 2017-02-15 13:43:30,608 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = user2 > 2017-02-15 13:43:30,610 TRACE [org.wildfly.security] (management task-10) Principal assigning: [user2], pre-realm rewritten: [user2], realm name: [ManagementRealm], post realm rewritten: [user2], realm rewritten: [user2] > 2017-02-15 13:43:30,614 TRACE [org.wildfly.security] (management task-10) Handling CredentialCallback: obtained successfully > 2017-02-15 13:43:30,615 TRACE [org.wildfly.security] (management task-10) Role mapping: principal [user2] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing principal user2. > 2017-02-15 13:43:30,616 TRACE [org.wildfly.security] (management task-10) Authorizing against the following attributes: [groups] => [] > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Permission mapping: identity [user2] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Authorization succeed > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) RunAs authorization succeed - the same identity > 2017-02-15 13:43:30,617 TRACE [org.wildfly.security] (management task-10) Handling AuthorizeCallback: authenticationID = user2 authorizationID = user2 authorized = true > 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling AuthenticationCompleteCallback: succeed > 2017-02-15 13:43:30,618 TRACE [org.wildfly.security] (management task-10) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@9b7d11 > 2017-02-15 13:43:30,640 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=null, MatchRule=[no user,host=localhost], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990] > 2017-02-15 13:43:30,641 TRACE [org.wildfly.security] (default task-2) getAuthenticationConfiguration uri=remote+http://localhost:9990, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, purpose=connect, MatchRule=[no user], AuthenticationConfiguration=[TrustManager,NamePrincipal=user1,realm=ManagementRealm,FilterSaslMechanism allow=true,name=[ DIGEST-MD5 ],Credentials,host=localhost,port=9990] > 2017-02-15 13:43:30,652 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback > 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling MechanismInformationCallback > 2017-02-15 13:43:30,653 TRACE [org.wildfly.security] (management I/O-1) Handling AvailableRealmsCallback: realms = [ManagementRealm] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling RealmCallback: selected = [ManagementRealm] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling NameCallback: authenticationName = user1 > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Principal assigning: [user1], pre-realm rewritten: [user1], realm name: [ManagementRealm], post realm rewritten: [user1], realm rewritten: [user1] > 2017-02-15 13:43:30,656 TRACE [org.wildfly.security] (management task-6) Handling CredentialCallback: obtained successfully > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Role mapping: principal [user1] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing principal user1. > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorizing against the following attributes: [groups] => [] > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Permission mapping: identity [user1] with roles [] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Authorization succeed > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) RunAs authorization succeed - the same identity > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthorizeCallback: authenticationID = user1 authorizationID = user1 authorized = true > 2017-02-15 13:43:30,657 TRACE [org.wildfly.security] (management task-6) Handling AuthenticationCompleteCallback: succeed > 2017-02-15 13:43:30,658 TRACE [org.wildfly.security] (management task-6) Handling SecurityIdentityCallback: identity = org.wildfly.security.auth.server.SecurityIdentity@53367941 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-298: --------------------------------- Fix Version/s: 1.1.0.Beta32 (was: 1.1.0.Beta31) > load-from/uri keystore xsd/parser mismatch > ------------------------------------------ > > Key: ELY-298 > URL: https://issues.jboss.org/browse/ELY-298 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta32 > > > The xsd has > {code} > <xsd:complexType name="key-store-type"> > <xsd:sequence minOccurs="1" maxOccurs="1"> >  > <xsd:choice minOccurs="1" maxOccurs="1"> > <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/> > {code} > The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-211) Client-side trust store configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-211: --------------------------------- Fix Version/s: 1.1.0.Beta32 (was: 1.1.0.Beta31) > Client-side trust store configuration > ------------------------------------- > > Key: ELY-211 > URL: https://issues.jboss.org/browse/ELY-211 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta32 > > > Lest I forget. The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB subsystems

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-181?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-181: --------------------------------- Fix Version/s: 1.1.0.Beta32 (was: 1.1.0.Beta31) > Review JACC in Servlet and EJB subsystems > ----------------------------------------- > > Key: ELY-181 > URL: https://issues.jboss.org/browse/ELY-181 > Project: WildFly Elytron > Issue Type: Sub-task > Components: API / SPI > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta32 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017