October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7178: ----------------------------------- Affects Version/s: (was: 11.0.0.Alpha1) > Review empty-role-decoder resource in Elytron subsystem > ------------------------------------------------------- > > Key: WFLY-7178 > URL: https://issues.jboss.org/browse/WFLY-7178 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration. > Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7178: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Review empty-role-decoder resource in Elytron subsystem > ------------------------------------------------------- > > Key: WFLY-7178 > URL: https://issues.jboss.org/browse/WFLY-7178 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 11.0.0.Alpha1 > > > We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration. > Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7278) Unable to add trust-manager with ldap-key-store (classloading)

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7278?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7278: ---------------------------------- Mentioned by Martin Chroma: The same exception will occure also if follows: 1. add ldap-key-store 2. remove ldap-key-store > Unable to add trust-manager with ldap-key-store (classloading) > -------------------------------------------------------------- > > Key: WFLY-7278 > URL: https://issues.jboss.org/browse/WFLY-7278 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > > When *ldap-key-store* is used in *trust-manager*, trust-manager creation fails: > {code:java} > Caused by: javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))]] > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:118) > at org.jboss.as.naming.InitialContext.init(InitialContext.java:99) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89) > at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) > at javax.naming.InitialContext.init(InitialContext.java:244) > at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222) > at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148) > at org.wildfly.security.keystore.LdapKeyStoreSpi.obtainDirContext(LdapKeyStoreSpi.java:120) > ... 16 more > java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.elytron:main" from local module loader @77a57272 (finder: local module finder @7181ae3f (roots: /home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules,/home/jkalina/wildfly/wildfly/build/target/wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:199) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:364) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:352) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:94) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:113) > ... 28 more > {code} > Direct key-store aliases listing using works ok: > {code:java} > /subsystem=elytron/ldap-key-store=LKS1/:read-children-names(child-type=alias) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7288) Elytron - inconsistency between DMR and XSD representation of ldap-realm

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7288: ---------------------------------- Summary: Elytron - inconsistency between DMR and XSD representation of ldap-realm Key: WFLY-7288 URL: https://issues.jboss.org/browse/WFLY-7288 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Optional There are inconsistencies between DMR and XSD representation of ldap-realm. * According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}. * According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}. * According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}. These inconsistencies should be unified. [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... [3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7288) Elytron - inconsistency between DMR and XSD representation of ldap-realm

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7288?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7288: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of ldap-realm > ------------------------------------------------------------------------ > > Key: WFLY-7288 > URL: https://issues.jboss.org/browse/WFLY-7288 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There are inconsistencies between DMR and XSD representation of ldap-realm. > * According to XSD [1] {{from}} attribute from user-password-mapper is required in ldap-realm. According to DMR {{from}} attribute is {{"nillable" => true}}. > * According to XSD [2] every attribute ({{algorithm-from}}, {{hash-from}}, {{seed-from}}, {{sequence-from}}) from otp-credential-mapper is required in ldap-realm. According to DMR all these attributes are {{"nillable" => true}}. > * According to XSD [3] {{name}} of {{attribute}} from new-identity-attributes is required in ldap-realm. According to DMR {{name}} of {{attribute}} is {{"nillable" => true}}. > These inconsistencies should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [3] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

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

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7287?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6384 to WFLY-7287: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7287 (was: JBEAP-6384) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR6) > User should be able to specify only one password mapper in jdbc-realm resource > ------------------------------------------------------------------------------ > > Key: WFLY-7287 > URL: https://issues.jboss.org/browse/WFLY-7287 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Pedro Igor > Priority: Minor > > 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 (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7286) Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7286?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7286: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7286 > URL: https://issues.jboss.org/browse/WFLY-7286 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}. > According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7286) Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-7286: ---------------------------------- Summary: Elytron - inconsistency between DMR and XSD representation of mechanism-provider-filtering-sasl-server-factory Key: WFLY-7286 URL: https://issues.jboss.org/browse/WFLY-7286 Project: WildFly Issue Type: Bug Components: Security Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Optional There is an inconsistency between DMR and XSD representation of {{mechanism-provider-filtering-sasl-server-factory}}. According to XSD [1] {{filters}} may not occur in {{mechanism-provider-filtering-sasl-server-factory}}. According to DMR {{filters}} is {{"nillable" => false}}. This should be unified. [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7285) Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7285?page=com.atlassian.jira.plugin.... ] Ondrej Lukas updated WFLY-7285: ------------------------------- Affects Version/s: 11.0.0.Alpha1 > Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper > -------------------------------------------------------------------------------------- > > Key: WFLY-7285 > URL: https://issues.jboss.org/browse/WFLY-7285 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Optional > > There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}. > According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2110: -------------------------------- Moving the parsing to the thread pool did *not* improve performance (UPerf, IspnPerfTest on cluster01-04). As a matter of fact, performance dropped slightly (~3-5%, with TCP)! Next step: use a buffer pool and refer to the buffer from Message.buf (+offset +length). Release the buffer when the message has been delivered. Complication for MessageBatch: release the buffer when all batches (read from a message list) have been delivered. > Transport: revisit buffers and threading > ---------------------------------------- > > Key: JGRP-2110 > URL: https://issues.jboss.org/browse/JGRP-2110 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > (Concerns only the receiver side) > h4. Parsing > Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down. > This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below). > h4. Buffers > * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message. > * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns > * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied. > h4. Approaches > # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation. > # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages. > # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up. > # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed. > h4. Goals > Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 3 months

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