November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1600) Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1600. -------------------------------------- Fix Version/s: 3.0.0.Alpha12 (was: 3.0.0.Alpha13) Resolution: Done > Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances. > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1600 > URL: https://issues.jboss.org/browse/WFCORE-1600 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha12 > > > These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-712) Elytron GSSCredential propagation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-712?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-712 at 11/10/16 6:58 AM: ---------------------------------------------------------- Require https://github.com/wildfly-security/wildfly-elytron/pull/434 [ELY-473] which is not merged yet. was (Author: honza889): [~mchoma] has said, that [~dlofthouse] has said, that this will require https://github.com/wildfly-security/wildfly-elytron/pull/434 [ELY-473] which is not merged yet. Looks like it is really needed for this.... > Elytron GSSCredential propagation > --------------------------------- > > Key: ELY-712 > URL: https://issues.jboss.org/browse/ELY-712 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: Jan Kalina > Assignee: Jan Kalina > > User can't achieve identity propagation scenario with elytron, so far: > # Client authenticate to web application using SPNEGO > # Web application calls another service (database, another web application, ... ) on behalf of user. > # Web applications wants to use provided gss credential, but there is no way to get associated credentials in elytron, so far > Basically use case tested in AS TS with legacy security [1] > Legacy approach using {{DelegationCredentialContext.getDelegCredential()}} return null in elytron. > Actually there exists pull request the delegated credential will be associated with the SecurityIdentity [2] . This JIRA is created mainly for tracking purpose to process it properly once pending commit gets to EAP. > [1] https://github.com/wildfly/wildfly/blob/15f9a4f2b5a10cc3acbaa2df57d5cc13d... testIdentityPropagation > [2] https://github.com/wildfly-security/wildfly-elytron/pull/434/commits/9b5a... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1313?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1313. -------------------------------------- Fix Version/s: 3.0.0.Alpha13 Resolution: Out of Date Resolving out of date as we are migrating to Elytron, it should be re-opened if the issue can be reproduced once migration is complete. > User with slash or backslash char in LDAP name cannot log in through security-realm > ----------------------------------------------------------------------------------- > > Key: WFCORE-1313 > URL: https://issues.jboss.org/browse/WFCORE-1313 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Lin Gao > Priority: Minor > Fix For: 3.0.0.Alpha13 > > Attachments: users.ldif > > > According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc. > I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there. > I can see this in Wireshark > *Slash/Char* > {code} > LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2 > {code} > You can see there quotation marks around *uid=Slash/Char*. > *Back\Slash* > {code} > LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6 > {code} > You can see there three backslash chars. > In my opinion problem can be somewhere around this > {code} > javax.naming.NameImpl.stringifyComp(String comp) > {code} > [1] https://tools.ietf.org/html/rfc2253#section-3 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-897) IPv6 address in security realm using Kerberos

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-897?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFCORE-897. ------------------------------------- Fix Version/s: 3.0.0.Alpha13 Assignee: Darran Lofthouse Resolution: Out of Date Resolving as out of date as we are migrating to Elytron for management security. > IPv6 address in security realm using Kerberos > --------------------------------------------- > > Key: WFCORE-897 > URL: https://issues.jboss.org/browse/WFCORE-897 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Optional > Fix For: 3.0.0.Alpha13 > > > When kerberos in realm is configured to use IPv6 address with square brackets, eg. [2620:52:0:2804:56ee:75ff:fe34:630e], EAP generates TGS-REQ for remote/2620:52:0:2804:56ee:75ff:fe34:630e instead of remote/[2620:52:0:2804:56ee:75ff:fe34:630e]. It cause failures when remote/[2620:52:0:2804:56ee:75ff:fe34:630e]@JBOSS.ORG is used in keytab. > This happens when such realm secures CLI or EJB remoting. It doesnt happen when used for securing management console." -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-496) add-user.sh - if password contains § it is not possible to log into the webinterface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-496?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFCORE-496. ------------------------------------- Fix Version/s: 3.0.0.Alpha13 Resolution: Rejected Management authentication is being moved to Elytron, this issue should be re-opened if the problem remains once the migration is complete. > add-user.sh - if password contains § it is not possible to log into the webinterface > ------------------------------------------------------------------------------------ > > Key: WFCORE-496 > URL: https://issues.jboss.org/browse/WFCORE-496 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Environment: wheezy, Firefox 34.0.5, Chrome 36.0.1985.125 > Reporter: do ev > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1100) One time password for management interfaces

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1100?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1100. -------------------------------------- Fix Version/s: 3.0.0.Alpha13 Assignee: Darran Lofthouse Resolution: Out of Date Management authentication is being migrated to WildFly Elytron so OTP support will be considered there. > One time password for management interfaces > ------------------------------------------- > > Key: WFCORE-1100 > URL: https://issues.jboss.org/browse/WFCORE-1100 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Common_Authentication > Fix For: 3.0.0.Alpha13 > > > This task is to look into one time password use for the management consoles. > This needs some further investigation as there is a trade off between ensuring a password is really one time and not valid for replays after use yet allowing a users web browser to keep establishing connections without forcing a new authentication every few minutes. > The native interface also needs similar consideration however the native interface does allow for connections to be kept open for a long time more naturally. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7549) Component upgrade Hibernate Validator to 5.3.1.Final

by Guillaume Smet (JIRA)

Guillaume Smet created WFLY-7549: ------------------------------------ Summary: Component upgrade Hibernate Validator to 5.3.1.Final Key: WFLY-7549 URL: https://issues.jboss.org/browse/WFLY-7549 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Guillaume Smet Assignee: Scott Marlow Fix For: 10.2.0.Final Hi, Hibernate Validator can be upgraded to the latest stable: Hibernate Validator 5.3.1.Final. API wise, there are very few changes except to features that were experimental. See our migration guide for 5.3 here: https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_co... I'm working on validating the upgrade in WildFly and preparing a PR. -- Guillaume -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2122) Streamable class might implement SizeStreamable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2122?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2122: --------------------------- Labels: Beta3 (was: ) > Streamable class might implement SizeStreamable > ----------------------------------------------- > > Key: JGRP-2122 > URL: https://issues.jboss.org/browse/JGRP-2122 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Labels: Beta3 > Fix For: 4.0 > > > Many classes implement Streamable, but also provide a serializedSize() method which returns the number of bytes needed for the serialized form. > Methods like Util.streamableToBuffer() could benefit from this: instead of allocating a 512 byte buffer, which is either too big or needs to be resized later, we can allocate a buffer of the exact size. > We should therefore make all classes implementing Streamable instead implement SizeStreamable. > Code that makes use of this: > {code:java|title=Util.streamableToBuffer()|borderStyle=solid} > public static Buffer streamableToBuffer(Streamable obj) { > int expected_size=obj instanceof SizeStreamable? > ((SizeStreamable)obj).serializedSize() +1 : 512; > final ByteArrayDataOutputStream out=new ByteArrayDataOutputStream(expected_size); > try { > Util.writeStreamable(obj,out); > return out.getBuffer(); > } > catch(Exception ex) { > return null; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2120) Headers.resize() called unnecessarily

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2120?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2120: --------------------------- Labels: Beta3 (was: ) > Headers.resize() called unnecessarily > ------------------------------------- > > Key: JGRP-2120 > URL: https://issues.jboss.org/browse/JGRP-2120 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Labels: Beta3 > Fix For: 3.6.12, 4.0 > > > Each message has space for 4 headers. When a 5th header needs to be added, the array needs to be resized. This is something we want to avoid as much as possible. > However, the following scenario can lead to resizing: > * A bundler writes a message list with (say) 3 headers > * A message list always ignores the transport header, as it is only used to carry the cluster name, but that name is available in the batch header, too. > * Therefore, the size of the headers written is 2 and the transport header is not written > * On the receiver side, when reading the batch, we create and read 2 headers > ** This is OK, as message batches are matched against the receiver's cluster name using the cluster name shipped in the batch itself and not in the message > ** Message batches are therefore passed up without the individual messages carrying a transport header > * However, single messages need to carry a transport header as it will be used to do the cluster name matching > * Now, if a batch contains messages tagged as {{OOB|DONT_BUNDLE}}, they will be removed from the batch and sent up the stack as separate messages, each in a separate thread. > * To do this, each of these messages is added a transport header (created using the batch's cluster name). > * However, this necessitates a resizing as the headers array has a length of only 2, but we now need 3 headers > Note that we don't run into this in 4.0, as Infinispan 9 (which uses 4) doesn't use {{DONT_BUNDLE}} any longer. It is still an unnecessary memory allocation and needs to be optimized. > However, we should fix it in 3.6 as we still use {{DONT_BUNDLE}} in Infinispan 8. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2124) ByteArrayDataOutputStream: expand more conservatively

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2124?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2124: --------------------------- Labels: Beta3 (was: ) > ByteArrayDataOutputStream: expand more conservatively > ----------------------------------------------------- > > Key: JGRP-2124 > URL: https://issues.jboss.org/browse/JGRP-2124 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Labels: Beta3 > Fix For: 4.0 > > > Currently, unless exponential growth is enabled, BADOSs expand as follows: > {{new_length = remaining_length + new bytes required + 32}} > If we have a 1024 buffer with pos=4 and want to add 1024 bytes, then we expand the buffer to 1020 + 1024 + 32 = 2076 bytes which is wasted space. > I'm changing this to > {{new_length = pos + new bytes required + 32}}. In the above example, we'd expand the buffer to 1060 bytes. > If we really wanted bigger expansion, exponential growth should be enabled. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

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 November 2016