September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-48) StringPrep use newer Unicode then StringPrep RFC 3454

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-48?page=com.atlassian.jira.plugin.sys... ] David Lloyd commented on ELY-48: -------------------------------- So... what is your proposed course of action? I don't really see this as being a problem. > StringPrep use newer Unicode then StringPrep RFC 3454 > ----------------------------------------------------- > > Key: ELY-48 > URL: https://issues.jboss.org/browse/ELY-48 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Darran Lofthouse > Priority: Minor > > RFC 3454 (StringPrep) define table of unassigned codepoints by Unicode 3.2: > http://tools.ietf.org/html/rfc3454#section-7 > But StringPrep implementation use {{java.lang.Character.getType()}}, which use newer Unicode, where same of defined unassigned codes are already assigned. > Examples: codepoint {{0x0221}}, {{0x0234}} and {{0x02EF}} > All are defined in RFC as unassigned but in Unicode 4.0.0 they are assigned: > http://www.fileformat.info/info/unicode/char/02EF/index.htm > I think using of newer Unicode can be tolerated, but it can depend on purpose of this profile of encode function. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz edited comment on WFLY-1067 at 9/30/14 2:40 PM: -------------------------------------------------------------------- This integration exercise is going to be tricky. The AS security infrastructure is completely based on a small set of mechanisms (callbacks, SSLContexts) and does not, as far as I can tell, give direct access to the initial configuration information, such as the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to the initial configuration information, like the password files and keystores. This could be helped by having some means to access the original configuration information for each mechanism. I suppose it could be looked up from the model in the addressable resource for the realm, given the realm and the mechanism. Whether or not this is legitimate or the best way of providing this information or will cause complications is another matter. was (Author: rachmato): This integration exercise is going to be tricky. The AS security infrastructure is completely based on mechanisms (callbacks, SSLContexts) and does not, as far as I can tell, give direct access to the initial configuration information, such as the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to the initial configuration information, like the password files and keystores. This could be helped by having some means to access the original configuration information for each mechanism. I suppose it could be looked up from the model in the addressable resource for the realm, given the realm and the mechanism. Whether or not this is legitimate or the best way of providing this information or will cause complications is another matter. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-1067: ------------------------------------------- This integration exercise is going to be tricky. The AS security infrastructure is completely based on mechanisms (callbacks, SSLContexts) and does not, as far as I can tell, give direct access to the initial configuration information, such as the underlying password files or keystores. JGroups AUTH and ENCRYPT protocols, on the other hand, do not make use of callbacks or pre-processed SSLContexts and assume access to the initial configuration information, like the password files and keystores. This could be helped by having some means to access the original configuration information for each mechanism. I suppose it could be looked up from the model in the addressable resource for the realm, given the realm and the mechanism. Whether or not this is legitimate or the best way of providing this information or will cause complications is another matter. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years

1
0
0 / 0

[JBoss JIRA] (JBJCA-1212) Pool could keep connections open after shutdown