[JBoss JIRA] (WFLY-7881) There is NoSuchProviderException when we want to create our custom credential store.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7881?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7881:
-------------------------------
Priority: Major (was: Critical)
> There is NoSuchProviderException when we want to create our custom credential store.
> ------------------------------------------------------------------------------------
>
> Key: WFLY-7881
> URL: https://issues.jboss.org/browse/WFLY-7881
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
>
> There is NoSuchProviderException when we want to create our custom credential store.
> *How to reproduce*
> # Create module
> Set your own path to customcredstoreprovider.jar downloaded from attachment
> {code}
> module add --name=org.jboss.customcredstore --resources=/tmp/customcredstoreprovider.jar --dependencies=org.wildfly.security.elytron,org.wildfly.extension.elytron --slot=main
> {code}
> # Create provider loader
> {code}
> /subsystem=elytron/provider-loader=cust001:add(providers=[{class-names=[org.jboss.as.test.integration.security.credential.store.CustomElytronProvider],module=org.jboss.customcredstore,load-services=true}],register=true)
> {code}
> # Create credential store
> {code}
> /subsystem=elytron/credential-store=cs0123456:add(uri="cr-store://test/customcredCS123.jceks?create.storage=true", provider=org.jboss.as.test.integration.security.credential.store.CustomElytronProvider, provider-loader=cust001, credential-reference={clear-text=pass123})
> {code}
> *And the result is:*
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.cs0123456" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.cs0123456: WFLYELY00004: Unable to start the service.
> Caused by: java.security.NoSuchProviderException: org.jboss.as.test.integration.security.credential.store.CustomElytronProvider"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store.cs0123456"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7881) There is NoSuchProviderException when we want to create our custom credential store.
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-7881:
----------------------------------
Summary: There is NoSuchProviderException when we want to create our custom credential store.
Key: WFLY-7881
URL: https://issues.jboss.org/browse/WFLY-7881
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
There is NoSuchProviderException when we want to create our custom credential store.
*How to reproduce*
# Create module
Set your own path to customcredstoreprovider.jar downloaded from attachment
{code}
module add --name=org.jboss.customcredstore --resources=/tmp/customcredstoreprovider.jar --dependencies=org.wildfly.security.elytron,org.wildfly.extension.elytron --slot=main
{code}
# Create provider loader
{code}
/subsystem=elytron/provider-loader=cust001:add(providers=[{class-names=[org.jboss.as.test.integration.security.credential.store.CustomElytronProvider],module=org.jboss.customcredstore,load-services=true}],register=true)
{code}
# Create credential store
{code}
/subsystem=elytron/credential-store=cs0123456:add(uri="cr-store://test/customcredCS123.jceks?create.storage=true", provider=org.jboss.as.test.integration.security.credential.store.CustomElytronProvider, provider-loader=cust001, credential-reference={clear-text=pass123})
{code}
*And the result is:*
{code}
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.cs0123456" => "org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.cs0123456: WFLYELY00004: Unable to start the service.
Caused by: java.security.NoSuchProviderException: org.jboss.as.test.integration.security.credential.store.CustomElytronProvider"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.credential-store.cs0123456"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7880) Wildfly 10 admin console does not show log files
by Davy Steegen (JIRA)
[ https://issues.jboss.org/browse/WFLY-7880?page=com.atlassian.jira.plugin.... ]
Davy Steegen updated WFLY-7880:
-------------------------------
Description:
When using "per deployment logging", the WildFly 10 admin console does not show the log files that I configured in my log4j configuration (only those that are managed via the WildFly itself).
You can find an example log4j configuration in the attachments. It contains a File appender that logs in a file called client.log (relative to the WildFly log directory).
The workaround is to create a Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.
Am I missing something or does this work as designed ?
was:
When using "per deployment logging", the WildFly 10 admin console does not show the log files that I configured in my log4j configuration (only those that are managed via the WildFly itself).
You can find an example log4j configuration in the attachments. It contains a File appender that logs in a file called client.log (relative to the WildFly log directory).
The workaround is to create Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.
Am I missing something or does this work as designed ?
> Wildfly 10 admin console does not show log files
> ------------------------------------------------
>
> Key: WFLY-7880
> URL: https://issues.jboss.org/browse/WFLY-7880
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 10.1.0.Final
> Reporter: Davy Steegen
> Assignee: James Perkins
> Attachments: log4j.properties
>
>
> When using "per deployment logging", the WildFly 10 admin console does not show the log files that I configured in my log4j configuration (only those that are managed via the WildFly itself).
> You can find an example log4j configuration in the attachments. It contains a File appender that logs in a file called client.log (relative to the WildFly log directory).
> The workaround is to create a Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.
> Am I missing something or does this work as designed ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7880) Wildfly 10 admin console does not show log files
by Davy Steegen (JIRA)
[ https://issues.jboss.org/browse/WFLY-7880?page=com.atlassian.jira.plugin.... ]
Davy Steegen updated WFLY-7880:
-------------------------------
Workaround Description: The workaround is to create a Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file. (was: The workaround is to create Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.)
> Wildfly 10 admin console does not show log files
> ------------------------------------------------
>
> Key: WFLY-7880
> URL: https://issues.jboss.org/browse/WFLY-7880
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 10.1.0.Final
> Reporter: Davy Steegen
> Assignee: James Perkins
> Attachments: log4j.properties
>
>
> When using "per deployment logging", the WildFly 10 admin console does not show the log files that I configured in my log4j configuration (only those that are managed via the WildFly itself).
> You can find an example log4j configuration in the attachments. It contains a File appender that logs in a file called client.log (relative to the WildFly log directory).
> The workaround is to create a Logging Handler of type File in the admin console per log file I want to monitor in the admin console. However, in our case the WildFly is managed by another team. We don't want to botter them each time we add a new log file.
> Am I missing something or does this work as designed ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek commented on WFLY-7153:
------------------------------------
Increasing priority to blocker. It is not possible to use custom provider.
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7153) Inconsistency of resources *-ssl-context in model vs. XSD
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7153?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek updated WFLY-7153:
-------------------------------
Priority: Blocker (was: Major)
> Inconsistency of resources *-ssl-context in model vs. XSD
> ---------------------------------------------------------
>
> Key: WFLY-7153
> URL: https://issues.jboss.org/browse/WFLY-7153
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
>
> * in client-ssl-context there is attribute {{security-domain}} in XSD, which is not in model. In case of client-ssl-context this probably does not make sense and reaaly should't be in XSD, neither.
> * in both *-ssl-context there is provider in XSD and provider-loader in model. Sync it please. Probably possibility to specify both could be useful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7058) JBoss CLI - CJK Character Issue
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-7058?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise commented on WFLY-7058:
--------------------------------------------
[~jprasanna], some fixes have been done in the way String are handed (just guessing that it could be the root cause). In a lot of places the Charset in use was the Platform default (so platform dependent). This has been fixed to explicitly use UTF-8.
Just curious, what Charset.defaultCharset() is printing on your system? On my Mac this is UTF-8.
Thanks.
JF
> JBoss CLI - CJK Character Issue
> -------------------------------
>
> Key: WFLY-7058
> URL: https://issues.jboss.org/browse/WFLY-7058
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.2.0.Final
> Reporter: J Prasanna Venkatesan
> Assignee: Darran Lofthouse
> Labels: cjk, login-module
> Attachments: cjk2.cli
>
>
> Dear All,
>
> Environment:
>
> CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> I am executing few LoginModule commands using file. My file name is command.cli
> Its content is
>
> {color:red}[root@cu490 temp]# cat command.cli
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapExtLoginModule3:add(code=org.jboss.security.auth.spi.LdapExtLoginModule, flag=sufficient, module-options={ "java.naming.provider.url" => "ldap://a.com:389/", "java.naming.referral" => "follow", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "java.naming.security.authentication" => "simple", "bindDN" => "cn=in00655,OU=비임직원,OU=SK이노베이션,DC=test,DC=net", "bindCredential" => "xxxxxx", "baseCtxDN" => "ou=SK이노베이션,DC=test,DC=net", "baseFilter" => "(sAMAccountName={0})", "roleAttributeID" => "memberOf", "roleAttributeIsDN" => "true", "rolesCtxDN" => "DC=test,DC=net", "roleFilter" => "(member={1})", "roleRecursion" => "1", "searchTimeLimit" => "5000", "searchScope" => "SUBTREE_SCOPE", "allowEmptyPasswords" => "false", "throwValidateError" => "true" }){allow-resource-service-restart=true}
>
> [root@cu490 temp]# /opt/collabnet/teamforge/runtime/jboss/bin/jboss-cli.sh --connect --file=command.cli
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> [root@cu490 temp]# vim /opt/collabnet/teamforge//runtime/jboss/standalone/configuration/standalone-full.xml{color}
>
> Content inside standalone-full.xml is
>
> {color:red}<login-module name="org.jboss.security.auth.spi.LdapExtLoginModule3" code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://a.com:389/"/>
> <module-option name="java.naming.referral" value="follow"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> <module-option name="bindDN" value="cn=in00655,OU=????,OU=SK?????,DC=test,DC=net"/>
> <module-option name="bindCredential" value="xxxxxx"/>
> <module-option name="baseCtxDN" value="ou=SK?????,DC=test,DC=net"/>
> <module-option name="baseFilter" value="(sAMAccountName={0})"/>
> <module-option name="roleAttributeID" value="memberOf"/>
> <module-option name="roleAttributeIsDN" value="true"/>
> <module-option name="rolesCtxDN" value="DC=test,DC=net"/>
> <module-option name="roleFilter" value="(member={1})"/>
> <module-option name="roleRecursion" value="1"/>
> <module-option name="searchTimeLimit" value="5000"/>
> <module-option name="searchScope" value="SUBTREE_SCOPE"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>{color}
>
> You can see instead of CJK characters we are seeing ??? in standalone-full.xml
>
> Please throw some light on this.
>
> Thanks & Regards,
> J Prasanna Venkatesan
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2186) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2186?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-2186:
------------------------------------------
Looking at the commands here we may still want to review the parameters for these operations.
If we are passing in a clear password there could be an argument for leaving out the salt and we generate one server side.
On the other hand if providing the salt and iteration count it may make more sense for the management client to pass in the hashed form of the password.
The modifiable realms are not going to be fully supported at this point whilst we work through some usability issues such as these comments but another option may be to add commands to the CLI that handle a lot of this.
Having said that these calls should still work with the current model, we may just evolve it slightly.
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2186
> URL: https://issues.jboss.org/browse/WFCORE-2186
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha16
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1937) Unneeded part of failure-description is printed in CLI for Elytron subsystem
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1937?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1937:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Unneeded part of failure-description is printed in CLI for Elytron subsystem
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1937
> URL: https://issues.jboss.org/browse/WFCORE-1937
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Affects Versions: 3.0.0.Alpha11
> Reporter: Ondrej Lukas
> Assignee: ehsavoie Hugonnet
> Labels: user_experience
>
> For some part of Elytron subsystem some unneeded part of message is printed in failure-description - messages with prefix {{WFLYCTL0412}} and {{WFLYCTL0180}} should not be part of failure-description since they are unneeded and confusing for this kind of failures (see example).
> Example:
> 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}
> Base on comment [1] we are assigning this Jira to Brian. Could you please clarify whether WildFly Core or Elytron subsystem are responsible for printing this message to failure-description?
> [1] https://issues.jboss.org/browse/JBEAP-6886?focusedCommentId=13317330&page...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1937) Unneeded part of failure-description is printed in CLI for Elytron subsystem
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1937?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-1937:
--------------------------------------
Component/s: Domain Management
> Unneeded part of failure-description is printed in CLI for Elytron subsystem
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1937
> URL: https://issues.jboss.org/browse/WFCORE-1937
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security, Server
> Affects Versions: 3.0.0.Alpha11
> Reporter: Ondrej Lukas
> Assignee: ehsavoie Hugonnet
> Labels: user_experience
>
> For some part of Elytron subsystem some unneeded part of message is printed in failure-description - messages with prefix {{WFLYCTL0412}} and {{WFLYCTL0180}} should not be part of failure-description since they are unneeded and confusing for this kind of failures (see example).
> Example:
> 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}
> Base on comment [1] we are assigning this Jira to Brian. Could you please clarify whether WildFly Core or Elytron subsystem are responsible for printing this message to failure-description?
> [1] https://issues.jboss.org/browse/JBEAP-6886?focusedCommentId=13317330&page...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months