[JBoss JIRA] (ELY-43) Clean up Base64
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys... ]
David Lloyd commented on ELY-43:
--------------------------------
I think that the benefits of Jason's implementation are on the micro-optimization scale. If we have to construct byte arrays and copy, we've lost that benefit in spades.
Mostly I just thought you'd find it interesting. :)
[~jason.greene] might have more input as he mainly implemented his version because he thought it was interesting.
Unrelatedly, I think it would be nice if we could get to a point where there's just one base 64 implementation across all of the WildFly project family which has all of the various capabilities we need. However this isn't possible without adding a dependency (on wildfly-common perhaps?) to Elytron (and of course moving this stuff there) - which is something [~dlofthouse] would have to comment on.
End rambling brain dump
> Clean up Base64
> ---------------
>
> Key: ELY-43
> URL: https://issues.jboss.org/browse/ELY-43
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.0.0.Beta1
>
>
> The Base64 implementation has been split out of PasswordUtils some additional steps are needed to finish cleaning it up: -
> - Look at switching to input and output streams instead of the custom iterators it is using.
> - Consider the ByteStringBuilder from SASL
> - As potentially more visible ensure clearer method names.
> - Ensure adequate javadoc and cross referencing of standards supported.
> e.g. If we implement an RFC ensure the number is referenced.
> - Testing of each variant
> - Consider optional support, e.g. decoding a padded String
> - Go beyond testing we can decode what we encode and ensure pre-encoded values can be handled adequately.
> Any other clean up here that seems relevant.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (ELY-43) Clean up Base64
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys... ]
Farah Juma commented on ELY-43:
-------------------------------
Took a look at the FlexBase64 implementation. We could replace the existing Base64 implementation with this one but we'd need to make at least the following modifications to it:
\\
\\
* Add support for the bcrypt and modular crypt alphabets (it currently supports the standard Base64 alphabet and a URL-safe variant of Base64)
* Add methods for encoding/decoding with an interleave table using the modular crypt style little-endian scheme
* Add methods for encoding/decoding a single byte
* Add a method for decoding an encoded character array
To get an idea of how this would change usage, consider the following examples:
1) Using the Base64 implementation, encoding a byte array, {{src}}, using the bcrypt alphabet and appending the result to a StringBuilder, {{b}}, is currently done like this:
{code}Base64.base64EncodeBCrypt(b, new ByteArrayInputStream(src));{code}
With a modified version of {{FlexBase64}}, the above might be done like this:
{code}b.append(FlexBase64.encodeString(src, false, FlexBase64.BCRYPT));{code}
2) Using the Base64 implementation, decoding a character array, {{encoded}}, into a byte array, {{bytes}}, using the standard alphabet, is currently done like this:
{code}byte[] bytes = Base64.base64DecodeStandard(encoded, 0){code}
With a modified version of {{FlexBase64}}, the above might look like this:
{code}
ByteBuffer b = FlexBase64.decode(encoded, 0, encoded.length, FlexBase64.STANDARD);
byte[] bytes = new byte[b.limit()];
b.get(bytes)
{code}
Any thoughts on this?
> Clean up Base64
> ---------------
>
> Key: ELY-43
> URL: https://issues.jboss.org/browse/ELY-43
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Utils
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Fix For: 1.0.0.Beta1
>
>
> The Base64 implementation has been split out of PasswordUtils some additional steps are needed to finish cleaning it up: -
> - Look at switching to input and output streams instead of the custom iterators it is using.
> - Consider the ByteStringBuilder from SASL
> - As potentially more visible ensure clearer method names.
> - Ensure adequate javadoc and cross referencing of standards supported.
> e.g. If we implement an RFC ensure the number is referenced.
> - Testing of each variant
> - Consider optional support, e.g. decoding a padded String
> - Go beyond testing we can decode what we encode and ensure pre-encoded values can be handled adequately.
> Any other clean up here that seems relevant.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-94:
-----------------------------------
One other thing. The -Dsecurity.manager build/test profile will have to be redone (again) to go back to the -secmgr flag behavior, and the default profile will have to be changed to always include the security manager subsystem.
> Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
> ---------------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties
by Vsevolod Golovanov (JIRA)
Vsevolod Golovanov created WFLY-3931:
----------------------------------------
Summary: Custom formatter property changes not written to, but overriden by logging.properties
Key: WFLY-3931
URL: https://issues.jboss.org/browse/WFLY-3931
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: 8.1.0.Final
Environment: Wildfly 8.1.0.Final
Reporter: Vsevolod Golovanov
Assignee: James Perkins
When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties.
If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties.
For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value.
But with more dynamic properties, e.g. that rely on system properties, it's not so simple...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (SECURITY-863) LogAuditProvider allocates too much
by Philippe Marschall (JIRA)
Philippe Marschall created SECURITY-863:
-------------------------------------------
Summary: LogAuditProvider allocates too much
Key: SECURITY-863
URL: https://issues.jboss.org/browse/SECURITY-863
Project: PicketBox
Issue Type: Patch
Components: JBossSX
Reporter: Philippe Marschall
Assignee: Stefan Guilhen
{{LogAuditProvider}} always logs the {{AuditEvent}} even if audit logging is disabled. This means the {{AuditEvent}} is always converted to a {{String}} even if the trace log level is disabled. The profiled our application and this causes a lot of allocations outside of TLABs for us even though we have audit logging disabled.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFCORE-94:
-----------------------------------
Additional work needed:
* Include an update to all the main module.xml files to include a dependency on the security manager module (the external project, not the subsystem module) (with imported services)
* Include a patch to the security manager subsystem to disable the security manager install() that it does
* Wildfly security manager dependency version needs to be updated to one which includes the meta-inf machinery that JBoss Modules requires
> Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
> ---------------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFCORE-94) Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFCORE-94:
------------------------------
Assignee: James Perkins (was: Kabir Khan)
> Add MODULE_OPTS to startup scripts and propagate -secmgr through the domain
> ---------------------------------------------------------------------------
>
> Key: WFCORE-94
> URL: https://issues.jboss.org/browse/WFCORE-94
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Scripts
> Reporter: Kabir Khan
> Assignee: James Perkins
> Fix For: 1.0.0.Alpha9
>
>
> The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain.
> The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1067:
-----------------------------------
This is a good writeup, thanks Richard.
I have a few additional comments:
* While usage of SASL without integrity/encryption support might be considered to be "not fully utilizing SASL", I'd like to point out that recent SASL mechanisms such as SCRAM no longer recommend or support encryption in any case, and recommend other options (SSL, channel binding) which provide other, more secure, encryption and integrity mechanisms. Instead modern SASL mechanisms focus on securing the authentication process itself, which (it seems to me) is still well-aligned with the point of using SASL in JGroups, which is to simply cover authentication in a secure, standards-adherent manner. So I recommend not worrying too much about QOP when you're considering the usage of SASL for new applications.
* The Elytron SPI is intended to be able to integrate at a lower level with authentication processes like this one. This means two things:
*# If you elect to use SASL, that integration should be particularly seamless and simple.
*# If you continue to support AUTH, you should have a much easier time acquiring and using credentials.
* In the short term, if you want to make this work *now*, I'd say you should do whatever you have to do to make it work sensibly. No hack is too ugly. :)
* In the medium to long term, please do communicate with the Elytron developers to ensure that any special requirements you have will be met.
> 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)
10 years