You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Christoph (Created) (JIRA)" <ji...@apache.org> on 2011/11/24 15:04:39 UTC
[jira] [Created] (KARAF-1037) karaf console command "jaas:adduser"
with encrypted password
karaf console command "jaas:adduser" with encrypted password
------------------------------------------------------------
Key: KARAF-1037
URL: https://issues.apache.org/jira/browse/KARAF-1037
Project: Karaf
Issue Type: Bug
Components: karaf-core
Affects Versions: 2.2.4
Environment: CentOS-5.7-x86_64, Mac OS X 10.7.2, Java 1.6.0_29
Reporter: Christoph
Priority: Minor
The karaf console shows a strange behavior when working with JAAS authentication modules and password encryption
Line of actions that lead to the issue:
(1) First of all, we've created a blueprint service containing the JAAS configuration
{noformat}
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0" xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">
<type-converters>
<bean class="org.apache.karaf.jaas.modules.properties.PropertiesConverter" />
</type-converters>
<!-- Allow usage of System properties, especially the karaf.base property -->
<ext:property-placeholder placeholder-prefix="$[" placeholder-suffix="]" />
<jaas:config name="myRealm">
<jaas:module className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule"
flags="required">
users = $[karaf.base]/etc/myUser.properties
encryption.enabled = true
encryption.prefix = {CRYPT}
encryption.suffix = {CRYPT}
encryption.algorithm = MD5
encryption.encoding = hexadecimal
</jaas:module>
</jaas:config>
</blueprint>
{noformat}
(2) After installing the realm as a feature in our service gateway, we configure two users with roles via the karaf command line interface
{noformat}
karaf@tesb> jaas:manage myRealm
karaf@tesb> jaas:useradd usr.app cert1
karaf@tesb> jaas:roleadd usr.app admin
karaf@tesb> jaas:roleadd usr.app dev
karaf@tesb> jaas:update
{noformat}
and can find something like the following entry in our myUser.properties file
{noformat}
usr.app = 510fd1dc93d0c601ad208ad700afc403,admin,dev
{noformat}
(3) When we execute a service call that triggers our authentication chain, the myUser.properties file changes to something like:
{noformat}
usr.app = {CRYPT}b3bef7f3d410589d471f93f6d55db6d4{CRYPT},admin,dev
{noformat}
This behaviour lead's us to the assumption, that the configuration via the karaf command line interface using JAAS commands does not create the encryption tag's but an initial hash set. When the application is using than the hash the first time, it does think that the password is not hashed yet, and creates a second hash with the pre- and suffix but makes the initial password useless.
Workaround for that issue is to avoid pre- and suffix for custom JAAS authentication modules
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KARAF-1037) karaf console command "jaas:adduser"
with encrypted password
Posted by "Christoph (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christoph updated KARAF-1037:
-----------------------------
Priority: Major (was: Minor)
> karaf console command "jaas:adduser" with encrypted password
> ------------------------------------------------------------
>
> Key: KARAF-1037
> URL: https://issues.apache.org/jira/browse/KARAF-1037
> Project: Karaf
> Issue Type: Bug
> Components: karaf-core
> Affects Versions: 2.2.4
> Environment: CentOS-5.7-x86_64, Mac OS X 10.7.2, Java 1.6.0_29
> Reporter: Christoph
> Labels: security
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The karaf console shows a strange behavior when working with JAAS authentication modules and password encryption
> Line of actions that lead to the issue:
> (1) First of all, we've created a blueprint service containing the JAAS configuration
> {noformat}
> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:jaas="http://karaf.apache.org/xmlns/jaas/v1.0.0"
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0" xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0">
> <type-converters>
> <bean class="org.apache.karaf.jaas.modules.properties.PropertiesConverter" />
> </type-converters>
> <!-- Allow usage of System properties, especially the karaf.base property -->
> <ext:property-placeholder placeholder-prefix="$[" placeholder-suffix="]" />
> <jaas:config name="myRealm">
> <jaas:module className="org.apache.karaf.jaas.modules.properties.PropertiesLoginModule"
> flags="required">
> users = $[karaf.base]/etc/myUser.properties
> encryption.enabled = true
> encryption.prefix = {CRYPT}
> encryption.suffix = {CRYPT}
> encryption.algorithm = MD5
> encryption.encoding = hexadecimal
> </jaas:module>
> </jaas:config>
> </blueprint>
> {noformat}
> (2) After installing the realm as a feature in our service gateway, we configure two users with roles via the karaf command line interface
> {noformat}
> karaf@tesb> jaas:manage myRealm
> karaf@tesb> jaas:useradd usr.app cert1
> karaf@tesb> jaas:roleadd usr.app admin
> karaf@tesb> jaas:roleadd usr.app dev
> karaf@tesb> jaas:update
> {noformat}
> and can find something like the following entry in our myUser.properties file
> {noformat}
> usr.app = 510fd1dc93d0c601ad208ad700afc403,admin,dev
> {noformat}
> (3) When we execute a service call that triggers our authentication chain, the myUser.properties file changes to something like:
> {noformat}
> usr.app = {CRYPT}b3bef7f3d410589d471f93f6d55db6d4{CRYPT},admin,dev
> {noformat}
> This behaviour lead's us to the assumption, that the configuration via the karaf command line interface using JAAS commands does not create the encryption tag's but an initial hash set. When the application is using than the hash the first time, it does think that the password is not hashed yet, and creates a second hash with the pre- and suffix but makes the initial password useless.
> Workaround for that issue is to avoid pre- and suffix for custom JAAS authentication modules
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira