[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-609:
---------------------------------
Fix Version/s: 1.1.0.Beta29
(was: 1.1.0.Beta28)
> Unguarded read in ElytronPolicyConfiguration
> --------------------------------------------
>
> Key: ELY-609
> URL: https://issues.jboss.org/browse/ELY-609
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: static_analysis
> Fix For: 1.1.0.Beta29
>
>
> Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-613:
---------------------------------
Fix Version/s: 1.1.0.Beta29
(was: 1.1.0.Beta28)
> Some nested classes should be considered to be static nested in Elytron
> -----------------------------------------------------------------------
>
> Key: ELY-613
> URL: https://issues.jboss.org/browse/ELY-613
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta7
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: static_analysis
> Fix For: 1.1.0.Beta29
>
>
> There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered:
> * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm
> * DecoderState from org.wildfly.security.asn1.DERDecoder
> * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm
> * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm
> * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-524:
---------------------------------
Fix Version/s: 1.1.0.Beta29
(was: 1.1.0.Beta28)
> 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.Beta29
>
>
> 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)
7 years, 4 months