[JBoss JIRA] (WFLY-7259) Review elytron kerberos-security-factory resource
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7259?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6287 to WFLY-7259:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7259 (was: JBEAP-6287)
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)
> Review elytron kerberos-security-factory resource
> -------------------------------------------------
>
> Key: WFLY-7259
> URL: https://issues.jboss.org/browse/WFLY-7259
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> * {{mechanism-oids}}
> ** Minimal command for kerberos security factory creation is {code}/subsystem=elytron/kerberos-security-factory=kerberos:add(principal=mchoma, path=/path/to/keytab, mechanism-oids=[1.2.840.113554.1.2.2]){code}
> ** I don't think it is user-friendly to require user to specify mechanism-oids. I think some reasonable default value should be used here.
> * {{minimum-remaining-lifetime}}
> ** please, specify units in documentation, e.g. seconds/minutes
> * {{relative-to}}
> ** as just path reference can be used here, probably should be just "expressions-allowed" => false
> ** In legacy settings it is documented better: "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute."
> * {{server}}
> ** I assume based on {{server}} attribute INITIATE_ONLY or ACCEPT_ONLY is configured on GSSCredential [1]. Wouldn't it be useful to have also possibility to set INITIATE_AND_ACCEPT? Couldn't that be useful for example in case of identity propagation.
> * {{for-hosts}}
> ** comparing to legacy security {{kerberosIdentityType}} I am missing for-hosts. Elytron won't provide such feature?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JGRP-2106) Prepare for JDK 9
by Bela Ban (JIRA)
Bela Ban created JGRP-2106:
------------------------------
Summary: Prepare for JDK 9
Key: JGRP-2106
URL: https://issues.jboss.org/browse/JGRP-2106
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0
Investigate the changes needed to run with JDK 9. Probably module.info classes are all that's needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7254) pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7254?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-7254:
------------------------------------
[~ivassile] In case when CLI commands should look like you mentioned in previous comments then command:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}
should lead to "outcome" => "failed".
Currently that command results to store both pattern-filter and predefined-filter in dynamic model, but only predefined-filter is stored in configuration. You can try:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:add(sasl-server-factory=global,filters=[{pattern-filter=(.*),predefined-filter=BINDING}])
{code}
then calling read-attribute operation is successful for both attribute:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].pattern-filter)
{
"outcome" => "success",
"result" => "(.*)"
}
{code}
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].predefined-filter)
{
"outcome" => "success",
"result" => "BINDING"
}
{code}
However after {{reload}} pattern-filter disappears:
{code}
/subsystem=elytron/configurable-sasl-server-factory=someFactory:read-attribute(name=filters[0].pattern-filter)
{
"outcome" => "failed",
"result" => undefined,
"failure-description" => "WFLYCTL0393: Could not resolve attribute expression: 'filters[0].pattern-filter'",
"rolled-back" => true
}
{code}
You should also note, that following part of configuration can be correctly loaded when server is started:
{code}
<configurable-sasl-server-factory name="someFactory" sasl-server-factory="global">
<filters>
<filter>
<pattern-filter value="(someFilter)"/>
<predefined-filter value="BINDING"/>
</filter>
</filters>
</configurable-sasl-server-factory>
{code}
> pattern-filter disappears if predefined-filter is used for configurable-sasl-server-factory in Elytron subsystem
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7254
> URL: https://issues.jboss.org/browse/WFLY-7254
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 11.0.0.Alpha1
>
>
> In case when configurable-sasl-server-factory is created through CLI with filter which uses both pattern-filter and predefined-filter, then only predefined-filter is stored into configuration (pattern-filter disappears).
> Suggestion:
> In case when usage of both filters is unsupported option, then it should be denied by CLI. In case when it is supported option, then both of them should be stored in configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7193:
-----------------------------
Description:
Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
Seems to me it would be useful for troubleshooting to have logged on
TRACE level:
- Keystore initialization with parameters
- Filtering keystore initialization with parameters
- KeyManager / TrustManager initialization with parameters
- Client / Server SSLContext initialization with parameters
WARN level:
- Certificate expired (on key store init, all certificates)
was:Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates)
> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
> Key: WFLY-7193
> URL: https://issues.jboss.org/browse/WFLY-7193
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on
> TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
> WARN level:
> - Certificate expired (on key store init, all certificates)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7193:
-----------------------------
Description: Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates) (was: Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
Seems to me it would be useful for troubleshooting to have logged on TRACE level:
- Keystore initialization with parameters
- Filtering keystore initialization with parameters
- KeyManager / TrustManager initialization with parameters
- Client / Server SSLContext initialization with parameters
)
> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
> Key: WFLY-7193
> URL: https://issues.jboss.org/browse/WFLY-7193
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.Seems to me it would be useful for troubleshooting to have logged on TRACE level:- Keystore initialization with parameters- Filtering keystore initialization with parameters- KeyManager / TrustManager initialization with parameters- Client / Server SSLContext initialization with parametersWARN level:- Certificate expired (on key store init, all certificates)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created
by Matt Smith (JIRA)
[ https://issues.jboss.org/browse/WFLY-7247?page=com.atlassian.jira.plugin.... ]
Matt Smith commented on WFLY-7247:
----------------------------------
I have also been experiencing this issue on Wildfly 9.0.1 and 9.0.2 (and 10). For me a single app out of about 8 that are deployed on the server always comes up without the SSO mechanism registered after a service restart. The other apps never exhibit this issue. Disabling and re-enabling the app brings it up with SSO registered. This pattern is 100% reliable - it happens on both nodes of our 2-node UAT cluster and all three nodes of our production cluster. Having a HTTPd reverse proxy server in front of the Wildfly server seems to trigger the behaviour.
> Wildfly 10 JSESSIONIDSSOs not being created
> -------------------------------------------
>
> Key: WFLY-7247
> URL: https://issues.jboss.org/browse/WFLY-7247
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: M Wardell
> Assignee: Jason Greene
>
> Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service.
> Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login.
> Details in the referenced forum thread.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-261:
---------------------------------------
No, I'll make 3.22.0-CR1 soon (tonight?). It supports Java 9.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months