[JBoss JIRA] (WFLY-7475) Complicated failure-descriptions in Elytron simple-permission-mapper
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFLY-7475:
----------------------------------
Summary: Complicated failure-descriptions in Elytron simple-permission-mapper
Key: WFLY-7475
URL: https://issues.jboss.org/browse/WFLY-7475
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
There are complicated failure-descriptions in Elytron simple-permission-mapper. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description.
Examples of complicated failure-description in simple-permission-mapper:
* Wrong name of permission class:
{code}
/subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.WrongLoginPermission,target-name=someName}]}])
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [org.wildfly.security.auth.permission.WrongLoginPermission].
Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"org.wildfly.security.auth.permission.WrongLoginPermission\"
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.permission.WrongLoginPermission from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
* Adding permission, but non existing module is used:
{code}
/subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.LoginPermission,target-name=someName,module=some.nonexist.module}]}])
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main
Caused by: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7475) Complicated failure-descriptions in Elytron simple-permission-mapper
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7475?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7475:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Complicated failure-descriptions in Elytron simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: WFLY-7475
> URL: https://issues.jboss.org/browse/WFLY-7475
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There are complicated failure-descriptions in Elytron simple-permission-mapper. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description.
> Examples of complicated failure-description in simple-permission-mapper:
> * Wrong name of permission class:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.WrongLoginPermission,target-name=someName}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [org.wildfly.security.auth.permission.WrongLoginPermission].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"org.wildfly.security.auth.permission.WrongLoginPermission\"
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.permission.WrongLoginPermission from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> * Adding permission, but non existing module is used:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.LoginPermission,target-name=someName,module=some.nonexist.module}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main
> Caused by: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7475) Complicated failure-descriptions in Elytron simple-permission-mapper
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7475?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7475:
-------------------------------
Labels: user_experience (was: )
> Complicated failure-descriptions in Elytron simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: WFLY-7475
> URL: https://issues.jboss.org/browse/WFLY-7475
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> There are complicated failure-descriptions in Elytron simple-permission-mapper. They include some details from exceptions which are not needed and can be confused for non-java administrators. Please handle these exceptions and provide some user friendly failure-description.
> Examples of complicated failure-description in simple-permission-mapper:
> * Wrong name of permission class:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.WrongLoginPermission,target-name=someName}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: WFLYELY00021: Exception while creating the permission object for the permission mapping. Please check [class-name], [target-name] (name of permission) and [action] of [org.wildfly.security.auth.permission.WrongLoginPermission].
> Caused by: org.wildfly.security.permission.InvalidPermissionClassException: ELY03015: Could not load permission class \"org.wildfly.security.auth.permission.WrongLoginPermission\"
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.auth.permission.WrongLoginPermission from [Module \"org.wildfly.extension.elytron:main\" from local module loader @5479e3f (finder: local module finder @27082746 (roots: /home/olukas/workspace/uxcli/jboss-eap-7.1/modules,/home/olukas/workspace/uxcli/jboss-eap-7.1/modules/system/layers/base))]"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> * Adding permission, but non existing module is used:
> {code}
> /subsystem=elytron/simple-permission-mapper=mapper:add(permission-mappings=[{permissions=[{action=read,class-name=org.wildfly.security.auth.permission.LoginPermission,target-name=someName,module=some.nonexist.module}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.mapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.mapper: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main
> Caused by: org.jboss.modules.ModuleNotFoundException: some.nonexist.module:main"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.mapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7473) Missing configurable options in elytron dir-context
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7473?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7473:
-------------------------------
Priority: Critical (was: Major)
> Missing configurable options in elytron dir-context
> ---------------------------------------------------
>
> Key: WFLY-7473
> URL: https://issues.jboss.org/browse/WFLY-7473
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Critical
>
> Elytron subsystem does not expose possibility to configure {{InitialLdapContext}} options:
> * com.sun.jndi.ldap.read.timeout
> * com.sun.jndi.ldap.connect.timeout
> Consider exposing general options like in case of legacy ldap outbound connection. Users relying on them could have problem to migrate to elytron.
> AFAICT it is already prepared in elytron, just elytron-subsystem part is missing.
> {code:title=SimpleDirContextFactoryBuilder.java}
> // set any additional connection property
> if (connectionProperties != null) {
> for (Object key : connectionProperties.keySet()) {
> Object value = connectionProperties.get(key.toString());
> if (value != null) {
> env.put(key.toString(), value.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7474) AccessControlException in OpenSSL initialization
by Josef Cacek (JIRA)
Josef Cacek created WFLY-7474:
---------------------------------
Summary: AccessControlException in OpenSSL initialization
Key: WFLY-7474
URL: https://issues.jboss.org/browse/WFLY-7474
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Josef Cacek
Assignee: Stuart Douglas
Priority: Critical
*Issue description*
When starting server with security manager (i.e. with {{-secmgr}} argument), then OpenSSL initialization fails with
{code}
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.wildfly.openssl.SSL.init(SSL.java:73)
at org.wildfly.openssl.SSL.getInstance(SSL.java:49)
at org.wildfly.openssl.OpenSSLEngine.<clinit>(OpenSSLEngine.java:59)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:47)
at io.undertow.protocols.alpn.OpenSSLAlpnProvider$1.run(OpenSSLAlpnProvider.java:43)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.protocols.alpn.OpenSSLAlpnProvider.<clinit>(OpenSSLAlpnProvider.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
at java.util.ServiceLoader$LazyIterator.access$700(ServiceLoader.java:323)
at java.util.ServiceLoader$LazyIterator$2.run(ServiceLoader.java:407)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:409)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at io.undertow.protocols.alpn.ALPNManager.<init>(ALPNManager.java:40)
at io.undertow.protocols.alpn.ALPNManager.<clinit>(ALPNManager.java:35)
at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:64)
at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:83)
at io.undertow.server.protocol.http.AlpnOpenListener.<init>(AlpnOpenListener.java:75)
at org.wildfly.extension.undertow.HttpsListenerService.createAlpnOpenListener(HttpsListenerService.java:101)
at org.wildfly.extension.undertow.HttpsListenerService.createOpenListener(HttpsListenerService.java:86)
at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:158)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "loadLibrary.wfssl")" in code source "(null <no signer certificates>)" of "org.wildfly.openssl.SSL$LibraryClassLoader@37072772")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at java.lang.SecurityManager.checkLink(SecurityManager.java:835)
at org.wildfly.security.manager.WildFlySecurityManager.checkLink(WildFlySecurityManager.java:338)
at java.lang.Runtime.loadLibrary0(Runtime.java:864)
at java.lang.System.loadLibrary(System.java:1122)
at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:180)
... 37 more
{code}
There could be a wrong class-loader used or {{doPrivileged()}} block missing, so the initializing code doesn't get the {{AllPermission}} (which is assigned to server modules).
*Suggested improvement*
* check and fix OpenSSL initialization, so it gets correct permissions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7462:
-------------------------------
Description:
Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
* trying to add duplicate service -> ERROR in server log
* missing required attribute of any resource attribute in CLI command -> ERROR in server log
* missing capability -> ERROR in server log
* ...
Some reasons why these logs should not be logged to server log:
* Adding useless messages to server log.
* This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
was:
Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
* trying to add duplicate resource -> ERROR in server log
* missing required attribute of any resource attribute in CLI command -> ERROR in server log
* missing capability -> ERROR in server log
* ...
Some reasons why these logs should not be logged to server log:
* Adding useless messages to server log.
* This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
> Do not log common CLI failures for Elytron to server log
> --------------------------------------------------------
>
> Key: WFLY-7462
> URL: https://issues.jboss.org/browse/WFLY-7462
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: user_experience
>
> Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
> * trying to add duplicate service -> ERROR in server log
> * missing required attribute of any resource attribute in CLI command -> ERROR in server log
> * missing capability -> ERROR in server log
> * ...
> Some reasons why these logs should not be logged to server log:
> * Adding useless messages to server log.
> * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
> These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas commented on WFLY-7462:
------------------------------------
[~brian.stansberry] It is interesting. I see this issue also in current WildFly build from master (SHA of last commit - {{a0038b04fef3c1822abd823ed35944be7650f8ab}}).
I am starting WildFly with standalone-elytron.xml. Start jboss-cli.sh and execute command mentioned in "Steps to Reproduce". Following occurs in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("properties-realm" => "realm")
]) - failure description: "WFLYCTL0155: path may not be null"
{code}
I looked again on this issue and it starts to be a little tricky here. Probably some validation occurs on CLI level which sometimes does not propagete exception to server log.
In case, when some required attribute of resource is missing, then it is probably validate by CLI and exception does not occurs in server log. Example:
{code}
/subsystem=elytron/properties-realm=realm:add()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0155: users-properties may not be null",
"rolled-back" => true
}
{code}
Attribute {{users-properties}} from resource {{properties-realm}} is missing, but no exception occurs.
In case when some required attribute of any attribute of resource is missing, then exception occurs in server log. Example:
{code}
/subsystem=elytron/properties-realm=realm:add(users-properties={})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0155: path may not be null",
"rolled-back" => true
}
{code}
Attribute {{path}} from attribute {{users-properties}} from resource {{properties-realm}} is missing and server log contains:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("properties-realm" => "realm")
]) - failure description: "WFLYCTL0155: path may not be null"
{code}
One of another possibility how to reproduce this issue is use the duplicate service (when I reported this issue, I incorrectly thought that duplicate resource causes ERROR in server log. It is caused by duplicate service - I will fix description). In case when you add ldap-realm with the same name as some properties-realm, then ERROR message also occurs in server log. Run server with standalone-elytron.xml (which already includes properties-realm=ManagementRealm) and run following commands:
{code}
/subsystem=elytron/dir-context=dir:add(url=localhost)
/subsystem=elytron/ldap-realm=ManagementRealm:add(dir-context=dir,identity-mapping={rdn-identifier=uid})
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.security.security-realm.ManagementRealm is already registered",
"rolled-back" => true
}
{code}
you will see in server log:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 8) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("ldap-realm" => "ManagementRealm")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.security.security-realm.ManagementRealm is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:239)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2416)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2416)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2174)
at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.performRuntime(LdapRealmDefinition.java:378)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1361)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:411)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:233)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
> Do not log common CLI failures for Elytron to server log
> --------------------------------------------------------
>
> Key: WFLY-7462
> URL: https://issues.jboss.org/browse/WFLY-7462
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: user_experience
>
> Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
> * trying to add duplicate resource -> ERROR in server log
> * missing required attribute of any resource attribute in CLI command -> ERROR in server log
> * missing capability -> ERROR in server log
> * ...
> Some reasons why these logs should not be logged to server log:
> * Adding useless messages to server log.
> * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
> These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7473) Missing configurable options in elytron dir-context
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7473?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6884 to WFLY-7473:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7473 (was: JBEAP-6884)
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.DR7)
> Missing configurable options in elytron dir-context
> ---------------------------------------------------
>
> Key: WFLY-7473
> URL: https://issues.jboss.org/browse/WFLY-7473
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
>
> Elytron subsystem does not expose possibility to configure {{InitialLdapContext}} options:
> * com.sun.jndi.ldap.read.timeout
> * com.sun.jndi.ldap.connect.timeout
> Consider exposing general options like in case of legacy ldap outbound connection. Users relying on them could have problem to migrate to elytron.
> AFAICT it is already prepared in elytron, just elytron-subsystem part is missing.
> {code:title=SimpleDirContextFactoryBuilder.java}
> // set any additional connection property
> if (connectionProperties != null) {
> for (Object key : connectionProperties.keySet()) {
> Object value = connectionProperties.get(key.toString());
> if (value != null) {
> env.put(key.toString(), value.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7472) Elytron key/trust-manager-factory default algorithm
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7472?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-6882 to WFLY-7472:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7472 (was: JBEAP-6882)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
> Elytron key/trust-manager-factory default algorithm
> ---------------------------------------------------
>
> Key: WFLY-7472
> URL: https://issues.jboss.org/browse/WFLY-7472
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> {{key-manager-factory}} and {{trust-manager-factory}} requires user to specify algorithm.
> Consider defaulting in elytron code to {{TrustManagerFactory.getDefaultAlgorithm()}} and {{KeyManagerFactory.getDefaultAlgorithm()}}.
> It is java portable as for oracle java it returns SunX509 and for Ibm java IbmX509.
> This JIRA is in scope of "user experience", minimizing necessary user input configuration.
> David: "The trust manager definitely should use the default algorithm when none is given; in this case the algorithm name isn't an "algorithm" per se, it's just an implementation name."
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7472) Elytron key/trust-manager-factory default algorithm
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7472?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7472:
-------------------------------
Labels: user_experience (was: )
> Elytron key/trust-manager-factory default algorithm
> ---------------------------------------------------
>
> Key: WFLY-7472
> URL: https://issues.jboss.org/browse/WFLY-7472
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> {{key-manager-factory}} and {{trust-manager-factory}} requires user to specify algorithm.
> Consider defaulting in elytron code to {{TrustManagerFactory.getDefaultAlgorithm()}} and {{KeyManagerFactory.getDefaultAlgorithm()}}.
> It is java portable as for oracle java it returns SunX509 and for Ibm java IbmX509.
> This JIRA is in scope of "user experience", minimizing necessary user input configuration.
> David: "The trust manager definitely should use the default algorithm when none is given; in this case the algorithm name isn't an "algorithm" per se, it's just an implementation name."
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months