January 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2161) username-load attribute of legacy LDAP Realm stop to work

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2161?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-7781 to WFCORE-2161: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-2161 (was: WFLY-7781) Component/s: Security (was: Security) > username-load attribute of legacy LDAP Realm stop to work > --------------------------------------------------------- > > Key: WFCORE-2161 > URL: https://issues.jboss.org/browse/WFCORE-2161 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha18 > > > {{username-load}} attribute of legacy LDAP Realm stop to work. This attribute is used for assigning username from some LDAP entry attribute. In current behavior username passed in credential is used as username even if username-load attribute is configured. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7843) Initial context factory is not able to be set in Elytron dir-context

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7843?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7843: ---------------------------------------- If we expose this we also need to keep in mind the ClassLoading as a module reference may also be required. > Initial context factory is not able to be set in Elytron dir-context > -------------------------------------------------------------------- > > Key: WFLY-7843 > URL: https://issues.jboss.org/browse/WFLY-7843 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Elytron subsystem does not allow to configure custom Initial context factory for dir-context. > Elytron {{org.wildfly.security.auth.realm.ldapSimpleDirContextFactoryBuilder}} includes setter for field {{initialContextFactory}}, but integration for Elytron subsystem is missing. This means that default value {{com.sun.jndi.ldap.LdapCtxFactory}} is always used by Application server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-644: ------------------------------------ Fix Version/s: 3.0.0.Alpha18 > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha18 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-644: ------------------------------------ Priority: Critical (was: Major) > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha18 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-583: ------------------------------------ Fix Version/s: 4.0.0.Beta1 > Think about interactive slave domain controller registration. > ------------------------------------------------------------- > > Key: WFCORE-583 > URL: https://issues.jboss.org/browse/WFCORE-583 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave. > As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible. > - Start slave domain controller disconnected. > - Start CLI and connect to slave using local auth. > - Execute join-domain(hostname, port) > At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store. > Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master. > The slave process generates a public and private key and with interaction with the administrator a certificate signing request. > The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave. > The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead. > Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs. > This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation. > Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1037) TrustManager algorithm of https ports can not be changed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1037?page=com.atlassian.jira.plugi... ] Darran Lofthouse resolved WFCORE-1037. -------------------------------------- Fix Version/s: 3.0.0.Alpha18 Resolution: Out of Date The migration to WildFly Elytron allows full control of the TrustManager definition. > TrustManager algorithm of https ports can not be changed > -------------------------------------------------------- > > Key: WFCORE-1037 > URL: https://issues.jboss.org/browse/WFCORE-1037 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Arto Huusko > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha18 > > > The trust manager algorithm used by undertow can not be changed. The server configuration file does not contain any support for changing the algorithm, nor is Java standard system property ssl.TrustManagerFactory.algorithm honored. Apparently undertow forces use of PKIX. > In earlier jboss versions jboss-web supported changing trust manager algorithm in the Connector element in the web server configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1228) Follow up on WFCORE-1202 and make the configuration available in the management model.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1228?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1228: ------------------------------------------ [~brian.stansberry] Does anyone else have a bit of time to pick this one up? Should just need a new attribute in the management model whilst we are in a position to add it. > Follow up on WFCORE-1202 and make the configuration available in the management model. > -------------------------------------------------------------------------------------- > > Key: WFCORE-1228 > URL: https://issues.jboss.org/browse/WFCORE-1228 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta1 > > > WFCORE-1202 makes use of a system property for configuration, this needs moving into the management model. > The system property should remain supported for backwards compatibility for those migrating from servers that relied on it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1533: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 3.0.0.Alpha18) > Integrate Management Access Control permission assignment with Elytron > ---------------------------------------------------------------------- > > Key: WFCORE-1533 > URL: https://issues.jboss.org/browse/WFCORE-1533 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 4.0.0.Beta1 > > > A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role. > Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection. > This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron. > After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based. > _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1696) Remove deprecated and legacy security realm integration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1696?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1696: ------------------------------------- Fix Version/s: 4.0.0.Beta1 > Remove deprecated and legacy security realm integration > ------------------------------------------------------- > > Key: WFCORE-1696 > URL: https://issues.jboss.org/browse/WFCORE-1696 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > At some point the legacy security realms and all of the related backwards compatibility integration should be removed leaving us with a pure Elytron backed solution. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1598: ------------------------------------- Priority: Critical (was: Major) > Conversion of Elytron SecurityIdentity to Subject for communication with older hosts. > ------------------------------------------------------------------------------------- > > Key: WFCORE-1598 > URL: https://issues.jboss.org/browse/WFCORE-1598 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha18 > > > In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request. > For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 January 2017