Skip to main content

Password aliases: just for passwords, or...?

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
12 replies [Last post]
ljnelson
Offline
Joined: 2003-08-04

Finally spent a good chunk of time and sorted out the word stew around
admin passwords, mapped passwords, user passwords, password files, password
aliases, etc. etc.

If I'm understanding correctly, in any configuration or password file
anywhere (that I might supply to asadmin via the --password file option),
or in arguments passed to, say, create-jdbc-connection-pool, I can
substitute tokens of the form:

${ALIAS=some-password-alias-name}

...where I would otherwise simply put a plaintext password value, and
assuming that I've created a password alias (using asadmin
create-password-alias some-password-alias-name) and set its value to the
"real" password, then the "real" password will be decrypted and used
instead, as though it had been typed directly into the file instead of the
${ALIAS=some-password-alias-name} token.

Is this look-up-the-real-value-from-an-encrypted-store functionality tied
to certain hard-wired properties (e.g. ones named "password", or...who
knows), or is it a general-purpose substitution mechanism?

Could I, for example, use it for hostnames (no idea why I would; just
curious as to the mechanism involved)? Could I, for example, set up a JDBC
connection pool whose databaseName property was set to
${ALIAS=some-database-name-alias}? Or does the aliasing mechanism somehow
"know" about "password" properties and is only invoked then?

The other question I had was more chicken-and-egg related.

This article (
http://kalali.me/learning-glassfish-v3-command-line-administration-inter...)
indicates that one could set up password aliases for use inside password
files.

So instead of typing this in a passwords.txt file somewhere:

AS_ADMIN_ADMINPASSWORD=fred

...I could do this:

AS_ADMIN_ADMINPASSWORD=${ALIAS=flintstone}

...and assuming I created a password alias whose name was flintstone and
whose value was fred, then everything would just work.

The article also indicated I could do this with the master password.
(Well, actually it was a little confusing. The text in question says this:

"Password aliasing is not present just for external resources, but it can
be used to protect the content of the password file which contains
administration and master password for using instead of typing the password
when the asadmin interactively asks for it. We can simply create a
password alias for administration password and for the master password and
use them in password file. Sample content for a password file with aliased
password is like.

AS_ADMIN_PASSWORD=${ALIAS=admin-alias}

AS_ADMIN_MAPPEDPASSWORD=${ALIAS=master-alias}"

(The confusing part is that Masoud has said "master" everywhere, but then
the line that uses the master-alias is actually AS_ADMIN_MAPPEDPASSWORD. I
didn't think mapped passwords (used by the create-connector-security-map
command, as mentioned here:
http://docs.oracle.com/cd/E18930_01/html/821-2433/asadmin-1m.html) had
anything to do with the master password.)

Anyway, assuming this was a typo and AS_ADMIN_MAPPEDPASSWORD should have
been AS_ADMIN_MASTERPASSWORD, I thought the master password was what
encrypted the password store in the first place. So the article says (with
the corrected (assumed) typo) I could do:

AS_ADMIN_MASTERPASSWORD=${ALIAS=master-alias}

...but in order for the asadmin command line utility to even process this
alias it...would have to know the master password, right? (I guess there
would be no HARM in doing this, it would just be redundant.)

Thanks for verifying my understanding here. I just like to know how the
magic works. :-)

Best,
Laird

--
http://about.me/lairdnelson

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tmueller
Offline
Joined: 2005-10-31

On 3/20/2012 1:18 PM, Laird Nelson wrote:
> Finally spent a good chunk of time and sorted out the word stew around
> admin passwords, mapped passwords, user passwords, password files,
> password aliases, etc. etc.
>
> If I'm understanding correctly, in any configuration or password file
> anywhere (that I might supply to asadmin via the --password file
> option), or in arguments passed to, say, create-jdbc-connection-pool,
> I can substitute tokens of the form:
>
> ${ALIAS=some-password-alias-name}
>
> ...where I would otherwise simply put a plaintext password value, and
> assuming that I've created a password alias (using asadmin
> create-password-alias some-password-alias-name) and set its value to
> the "real" password, then the "real" password will be decrypted and
> used instead, as though it had been typed directly into the file
> instead of the ${ALIAS=some-password-alias-name} token.
>
> Is this look-up-the-real-value-from-an-encrypted-store functionality
> tied to certain hard-wired properties (e.g. ones named "password",
> or...who knows), or is it a general-purpose substitution mechanism?
It is a general-purpose substitution mechanism that works on any
attribute in the domain.xml. If you are interested in the details, there
is a GlassFish source file called TranslatedConfigView.java that does
the substitution.
>
> Could I, for example, use it for hostnames (no idea why I would; just
> curious as to the mechanism involved)?
Yes.
> Could I, for example, set up a JDBC connection pool whose databaseName
> property was set to ${ALIAS=some-database-name-alias}?
Yes.
> Or does the aliasing mechanism somehow "know" about "password"
> properties and is only invoked then?
No.

Note that alias substitution has to be for the whole value, i.e.,

value="abc${ALIAS=analias}xyz"

will not work.

>
> The other question I had was more chicken-and-egg related.
>
> This article
> (http://kalali.me/learning-glassfish-v3-command-line-administration-inter...)
> indicates that one could set up password aliases for use inside
> password files.
>
> So instead of typing this in a passwords.txt file somewhere:
>
> AS_ADMIN_ADMINPASSWORD=fred
>
> ...I could do this:
>
> AS_ADMIN_ADMINPASSWORD=${ALIAS=flintstone}
>
> ...and assuming I created a password alias whose name was flintstone
> and whose value was fred, then everything would just work.
>
> The article also indicated I could do this with the master password.
> (Well, actually it was a little confusing. The text in question says
> this:
>
> "Password aliasing is not present just for external resources, but it
> can be used to protect the content of the password file which contains
> administration and master password for using instead of typing the
> password when the asadmin interactively asks for it. We can simply
> create a password alias for administration password and for the master
> password and use them in password file. Sample content for a password
> file with aliased password is like.
>
> |AS_ADMIN_PASSWORD=${ALIAS=admin-alias}|
>
> |AS_ADMIN_MAPPEDPASSWORD=${ALIAS=master-alias}"|
>
>
> (The confusing part is that Masoud has said "master" everywhere, but
> then the line that uses the master-alias is actually
> AS_ADMIN_MAPPEDPASSWORD. I didn't think mapped passwords (used by the
> create-connector-security-map command, as mentioned here:
> http://docs.oracle.com/cd/E18930_01/html/821-2433/asadmin-1m.html) had
> anything to do with the master password.)
>
> Anyway, assuming this was a typo and AS_ADMIN_MAPPEDPASSWORD should
> have been AS_ADMIN_MASTERPASSWORD, I thought the master password was
> what encrypted the password store in the first place. So the article
> says (with the corrected (assumed) typo) I could do:
>
> AS_ADMIN_MASTERPASSWORD=${ALIAS=master-alias}
>
> ...but in order for the asadmin command line utility to even process
> this alias it...would have to know the master password, right? (I
> guess there would be no HARM in doing this, it would just be redundant.)
Yes, you are correct. The two passwords that cannot be aliased in a
password file are the AS_ADMIN_PASSWORD and AS_ADMIN_MASTERPASSWORD,
because you have to authenticate with the server (the first one) and be
able to open the domain-passwords file (the second one) in order to do
password aliasing.

Tom

>
> Thanks for verifying my understanding here. I just like to know how
> the magic works. :-)
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>

ljnelson
Offline
Joined: 2003-08-04

On Tue, Mar 20, 2012 at 5:48 PM, Tom Mueller wrote:

> On 3/20/2012 1:18 PM, Laird Nelson wrote:
>
> Is this look-up-the-real-value-from-an-encrypted-store functionality tied
> to certain hard-wired properties (e.g. ones named "password", or...who
> knows), or is it a general-purpose substitution mechanism?
>
> It is a general-purpose substitution mechanism that works on any attribute
> in the domain.xml. If you are interested in the details, there is a
> GlassFish source file called TranslatedConfigView.java that does the
> substitution.
>

Excellent; figured as much--but could also make a relatively strong case
for a special-purpose "password only" implementation, which is why I
asked. Thanks again.

> Note that alias substitution has to be for the whole value, i.e.,
>
> value="abc${ALIAS=analias}xyz"
>
> will not work.
>

Oh, good to know.

> The two passwords that cannot be aliased in a password file are the
> AS_ADMIN_PASSWORD and AS_ADMIN_MASTERPASSWORD, because you have to
> authenticate with the server (the first one) and be able to open the
> domain-passwords file (the second one) in order to do password aliasing.
>

Excellent; so some portions of that article are working more or less by
chance, or simply because the user has to specify the information anyway.
Got it.

At the risk of running off on a tangent, and it's probably in the
Administration Guide, surely, but I've also seen property substitutions
like this:

${SOME_VALUE}

Are these system properties? Environment variables? Is this the usual de
facto standard Java system property substitution, or are these always
well-known values (most seem to be things like (if memory serves)
${as_install_root}, which look faintly magical)? If I use asadmin
create-system-property (or whatever that subcommand is), could I supply
these values as well?

Thanks for your help (and patience!).

Best,
Laird

--
http://about.me/lairdnelson

tmueller
Offline
Joined: 2005-10-31

On 3/20/2012 9:38 PM, Laird Nelson wrote:
>
> At the risk of running off on a tangent, and it's probably in the
> Administration Guide, surely, but I've also seen property
> substitutions like this:
>
> ${SOME_VALUE}
>
> Are these system properties?
Yes.
> Environment variables? Is this the usual de facto standard Java
> system property substitution, or are these always well-known values
> (most seem to be things like (if memory serves) ${as_install_root},
> which look faintly magical)? If I use asadmin create-system-property
> (or whatever that subcommand is), could I supply these values as well?
These can be any system property value, including those passed with -D
on the java command line (use create-jvm-options to set) and system
properties (use create-system-properties to set).

Also, these substitutions can be nested in a string, so you can do:

value="some ${abc} string ${def}"

where abc and def are system properties.

Tom

>
> Thanks for your help (and patience!).
>
> Best,
> Laird
>
>
> --
> http://about.me/lairdnelson
>

ljnelson
Offline
Joined: 2003-08-04

On Wed, Mar 21, 2012 at 9:16 AM, Tom Mueller wrote:

> These can be any system property value, including those passed with -D on
> the java command line (use create-jvm-options to set) and system properties
> (use create-system-properties to set).
>

Great; thanks. FWIW I noticed that the Administration Guide doesn't make
mention of this really excellent facility (or at least searches for "system
property" and "system properties" in my PDF reader turned up how to set
them, but not that they get expanded when in ${dollarBracket} form).

Does this also mean that I could use them in deployment descriptor files
(perhaps non-portably)? Or only domain.xml configurations (and templates)?

For example, if I put this in a persistence.xml somewhere:

${myApplicationDataSource}

...would it expand (if the property is set, of course)? (If the property
were not set, would it expand to the empty string, or to the literal string
"${myApplicationDataSource}"?)

I recognize this is probably a crazy thing to do and am not entirely
serious here; just trying to grok all the possibilities. (It has always
bothered me that whereas all the other deployment descriptors offer up a
level of indirection for resource references, I have to specifically
mention a global JNDI lookup (which could of course be java:app/env-scoped)
for a data source.)

Best,
Laird

--
http://about.me/lairdnelson

tmueller
Offline
Joined: 2005-10-31

On 3/21/2012 11:12 AM, Laird Nelson wrote:
> On Wed, Mar 21, 2012 at 9:16 AM, Tom Mueller > wrote:
>
> These can be any system property value, including those passed
> with -D on the java command line (use create-jvm-options to set)
> and system properties (use create-system-properties to set).
>
>
> Great; thanks. FWIW I noticed that the Administration Guide doesn't
> make mention of this really excellent facility (or at least searches
> for "system property" and "system properties" in my PDF reader turned
> up how to set them, but not that they get expanded when in
> ${dollarBracket} form).
>
> Does this also mean that I could use them in deployment descriptor
> files (perhaps non-portably)? Or only domain.xml configurations (and
> templates)?
Only domain.xml.

Cheers,
Tom
>
> For example, if I put this in a persistence.xml somewhere:
>
> ${myApplicationDataSource}
>
> ...would it expand (if the property is set, of course)? (If the
> property were not set, would it expand to the empty string, or to the
> literal string "${myApplicationDataSource}"?)
>
> I recognize this is probably a crazy thing to do and am not entirely
> serious here; just trying to grok all the possibilities. (It has
> always bothered me that whereas all the other deployment descriptors
> offer up a level of indirection for resource references, I have to
> specifically mention a global JNDI lookup (which could of course be
> java:app/env-scoped) for a data source.)
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>

ljnelson
Offline
Joined: 2003-08-04

On Wed, Mar 21, 2012 at 12:29 PM, Tom Mueller wrote:

> Only domain.xml.
>

Thanks, Tom. One last question about password aliases.

I used one in setting up an LDAP realm. The command line worked great. I
did notice that the actual password value is present in the GUI. That is,
the text box in question under the Additional Properties tab contains the
actual password *value*, not the literal string
${ALIAS=the-alias-name-I-chose}. The good news is of course that the
password alias decoding obviously worked, as the value present in this box
is correct. The bad news--or much more likely my simple
misunderstanding--is that the raw password value itself is now present in
the admin console.

Obviously in order to create a password alias in the first place you need
to have the admin password, but it's still kind of jarring to see this
plaintext value in the GUI. Was that by design, or should I file a bug? I
would have expected to see the literal string
${ALIAS=the-alias-name-I-chose} in the GUI, but perhaps I'm missing
something.

Thanks,
Laird

--
http://about.me/lairdnelson

anilam
Offline
Joined: 2005-03-29

Hi Laird,

On 3/25/12 5:36 PM, Laird Nelson wrote:
> On Wed, Mar 21, 2012 at 12:29 PM, Tom Mueller > wrote:
>
> Only domain.xml.
>
>
> Thanks, Tom. One last question about password aliases.
>
> I used one in setting up an LDAP realm. The command line worked
> great. I did notice that the actual password value is present in the
> GUI. That is, the text box in question under the Additional
> Properties tab contains the actual password *value*, not the literal
> string ${ALIAS=the-alias-name-I-chose}.
I assume you are using the console to create this LDAP realm. You
specify the property value to be ${ALIAS=the-alias-name-i-use}, and
then when you look at the page again, the property value is decoded to
be the actual password.

I tried and experience the same thing as you are seeing.
I notice that even though the console is passing in
${ALIAS=the-alias-name-i-choose} to the backend to create the realm, it
is written out to domain.xml with the value decoded.
I am seeing this in domain.xml after the creation:

**

with the REST request
[#|2012-03-25T21:40:19.176-0700|FINEST|glassfish3.1.2|org.glassfish.admingui|_ThreadID=25;_ThreadName=admin-thread-pool-4848(6);ClassName=org.glassfish.admingui.common.util.RestUtil;MethodName=restRequest;|restRequest:
endpoint=http://localhost:4848/management/domain/configs/config/server-config/security-service/auth-realm
attrs={name=myLdapRealm,
classname=com.sun.enterprise.security.auth.realm.ldap.LDAPRealm,
target=server-config,
property=T*EST="${ALIAS=the-alias-name-i-choose}"*:jaas-context=ldapRealm:base-dn="C=US":directory="/tmp":}
method=post|#]

thats why you are seeing the decoded value in the console after the
creation.

I see that this happens only when creating the realm. If the property
is added AFTER the realm is created, ie during editing, then it will be
written out to domain.xml as the alias and console will also show that
correctly.

Please file a bug on this. create-auth-realm command should not decode
and write out the password in plain text in domain.xml when user is
using a password alias.

I tried to see how it behaves when using CLI to create the realm.
Unfortunately, I cannot get CLI to work correctly although i think
thats the correct syntax.

I tried:
%asadmin create-auth-realm --classname
com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property
*TEST="${ALIAS=the-alias-name-i-choose}"*:jaas-context=ldapRealm:base-dn=foo:directory=/tmp
ldap2
Command create-auth-realm executed successfully.

and see this in domain.xml

* *

Tom, am i using the correct syntax or if this is another issue with
create-auth-realm when using password alias ?

thanks
Anissa.

> The good news is of course that the password alias decoding obviously
> worked, as the value present in this box is correct. The bad news--or
> much more likely my simple misunderstanding--is that the raw password
> value itself is now present in the admin console.
>
> Obviously in order to create a password alias in the first place you
> need to have the admin password, but it's still kind of jarring to see
> this plaintext value in the GUI. Was that by design, or should I file
> a bug?
> I would have expected to see the literal string
> ${ALIAS=the-alias-name-I-chose} in the GUI, but perhaps I'm missing
> something.

>
> Thanks,
> Laird
>
> --
> http://about.me/lairdnelson
>

tmueller
Offline
Joined: 2005-10-31

Here's the syntax that I use with the bash shell:

asadmin create-auth-realm --classname
com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property
'TEST=${ALIAS\=myalias}:jaas-context=ldapRealm:base-dn=foo:directory=/tmp'
ldap2

Note the use of single quotes (') around the property list and the
escaped equal sign (=) in the alias.

The command line with csh might be different - I don't typically use csh.

Tom

On 3/26/2012 12:09 AM, Anissa Lam wrote:
> Hi Laird,
>
> On 3/25/12 5:36 PM, Laird Nelson wrote:
>> On Wed, Mar 21, 2012 at 12:29 PM, Tom Mueller > > wrote:
>>
>> Only domain.xml.
>>
>>
>> Thanks, Tom. One last question about password aliases.
>>
>> I used one in setting up an LDAP realm. The command line worked
>> great. I did notice that the actual password value is present in the
>> GUI. That is, the text box in question under the Additional
>> Properties tab contains the actual password *value*, not the literal
>> string ${ALIAS=the-alias-name-I-chose}.
> I assume you are using the console to create this LDAP realm. You
> specify the property value to be ${ALIAS=the-alias-name-i-use}, and
> then when you look at the page again, the property value is decoded
> to be the actual password.
>
> I tried and experience the same thing as you are seeing.
> I notice that even though the console is passing in
> ${ALIAS=the-alias-name-i-choose} to the backend to create the realm,
> it is written out to domain.xml with the value decoded.
> I am seeing this in domain.xml after the creation:
>
> classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
>
>
> **
>
>
>
> with the REST request
> [#|2012-03-25T21:40:19.176-0700|FINEST|glassfish3.1.2|org.glassfish.admingui|_ThreadID=25;_ThreadName=admin-thread-pool-4848(6);ClassName=org.glassfish.admingui.common.util.RestUtil;MethodName=restRequest;|restRequest:
> endpoint=http://localhost:4848/management/domain/configs/config/server-config/security-service/auth-realm
> attrs={name=myLdapRealm,
> classname=com.sun.enterprise.security.auth.realm.ldap.LDAPRealm,
> target=server-config,
> property=T*EST="${ALIAS=the-alias-name-i-choose}"*:jaas-context=ldapRealm:base-dn="C=US":directory="/tmp":}
> method=post|#]
>
> thats why you are seeing the decoded value in the console after the
> creation.
>
> I see that this happens only when creating the realm. If the
> property is added AFTER the realm is created, ie during editing, then
> it will be written out to domain.xml as the alias and console will
> also show that correctly.
>
> Please file a bug on this. create-auth-realm command should not
> decode and write out the password in plain text in domain.xml when
> user is using a password alias.
>
> I tried to see how it behaves when using CLI to create the realm.
> Unfortunately, I cannot get CLI to work correctly although i think
> thats the correct syntax.
>
> I tried:
> %asadmin create-auth-realm --classname
> com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property
> *TEST="${ALIAS=the-alias-name-i-choose}"*:jaas-context=ldapRealm:base-dn=foo:directory=/tmp
> ldap2
> Command create-auth-realm executed successfully.
>
> and see this in domain.xml
> classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
>
>
> * *
>
>
>
> Tom, am i using the correct syntax or if this is another issue with
> create-auth-realm when using password alias ?
>
> thanks
> Anissa.
>
>> The good news is of course that the password alias decoding obviously
>> worked, as the value present in this box is correct. The bad
>> news--or much more likely my simple misunderstanding--is that the raw
>> password value itself is now present in the admin console.
>>
>> Obviously in order to create a password alias in the first place you
>> need to have the admin password, but it's still kind of jarring to
>> see this plaintext value in the GUI. Was that by design, or should I
>> file a bug?
>> I would have expected to see the literal string
>> ${ALIAS=the-alias-name-I-chose} in the GUI, but perhaps I'm missing
>> something.
>
>>
>> Thanks,
>> Laird
>>
>> --
>> http://about.me/lairdnelson
>>
>

ljnelson
Offline
Joined: 2003-08-04

On Mon, Mar 26, 2012 at 10:03 AM, Tom Mueller wrote:

> Here's the syntax that I use with the bash shell:
>
> asadmin create-auth-realm --classname
> com.sun.enterprise.security.auth.realm.ldap.LDAPRealm --property
> 'TEST=${ALIAS\=myalias}:jaas-context=ldapRealm:base-dn=foo:directory=/tmp'
> ldap2
>
> Note the use of single quotes (') around the property list and the escaped
> equal sign (=) in the alias.
>

Thanks for that; yes, that's what I finally ended up with (on csh too,
FWIW).

To be (perhaps too) clear, this does not fix the issue (just corrects any
asadmin create-auth-realm syntax errors from my prior postings). Thanks!

Best,
Laird

--
http://about.me/lairdnelson

ljnelson
Offline
Joined: 2003-08-04

On Mon, Mar 26, 2012 at 1:09 AM, Anissa Lam wrote:

> On 3/25/12 5:36 PM, Laird Nelson wrote:
>
> I used [a password alias] in setting up an LDAP realm. The command line
> worked great. I did notice that the actual password value is present in
> the GUI.
>
> I assume you are using the console to create this LDAP realm. You specify
> the property value to be ${ALIAS=the-alias-name-i-use}, and then when you
> look at the page again, the property value is decoded to be the actual
> password.
>

Yes, except that I actually used the command line (on Linux):

asadmin --port=7048
create-auth-realm--classname
"com.sun.enterprise.security.auth.realm.ldap.LDAPRealm"
--property "jaas-context=ldapRealm:directory=ldap\://myhost.goes.here\:389
:base-dn=ou\=Users,ou\=SomeOrgUnit,o\=mycompany.com:search-filter=cn\=%s
:group-base-dn=ou\=Roles,ou\=SomeOrgUnit,o\=mycompany.com
:group-search-filter=member\=%d:group-target=cn:search-bind-dn=
cn\=adminuser,ou\=Users,ou\=SomeOrgUnit,o\=mycompany.com:search-bind-password=${ALIAS=ldaprealm-password}"
"MyRealm"

I did run into some troubles with equals signs (as you might expect), but a
combination of backslashes and quoting solved the problem (as you also
might expect :-)). In reality, I can't remember whether the --property
option was quoted with single quotes or double quotes; I believe that
actually as I have it written above there's still going to be a case where
the shell wants to jump in and try to expand ${ALIAS=ldaprealm-password} in
some way; I may be missing a backslash or two above. (This formulation
above is the only record I have of a series of attempts I made.)

> I tried and experience the same thing as you are seeing.
> I notice that even though the console is passing in
> ${ALIAS=the-alias-name-i-choose} to the backend to create the realm, it is
> written out to domain.xml with the value decoded.
>

Oh, I didn't even check that...

{time passes}

...yep; here too.

> I am seeing this in domain.xml after the creation:
>
> classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
>
>
> * *
> value="ldapRealm">
>
>

Yes.

> Please file a bug on this. create-auth-realm command should not decode
> and write out the password in plain text in domain.xml when user is using a
> password alias.
>

Good; I didn't think so. Bug filed:
http://java.net/jira/browse/GLASSFISH-18557

Best,
Laird

--
http://about.me/lairdnelson

Nithya Subraman...
Offline
Joined: 2011-03-21

Hi,

This was an issue which was fixed recently (on Feb 3). The aliases
should work with the create-auth-realm commands in the latest builds.

Thanks
Nithya

On Monday 26 March 2012 06:07 PM, Laird Nelson wrote:
> On Mon, Mar 26, 2012 at 1:09 AM, Anissa Lam > wrote:
>
> On 3/25/12 5:36 PM, Laird Nelson wrote:
>> I used [a password alias] in setting up an LDAP realm. The
>> command line worked great. I did notice that the actual password
>> value is present in the GUI.
>
> I assume you are using the console to create this LDAP realm. You
> specify the property value to be ${ALIAS=the-alias-name-i-use},
> and then when you look at the page again, the property value is
> decoded to be the actual password.
>
>
> Yes, except that I actually used the command line (on Linux):
>
> asadmin --port=7048 create-auth-realm
> --classname
> "com.sun.enterprise.security.auth.realm.ldap.LDAPRealm" --property
> "jaas-context=ldapRealm:directory=ldap\://myhost.goes.here\:389:base-dn=ou\=Users,ou\=SomeOrgUnit,o\=mycompany.com
> :search-filter=cn\=%s:group-base-dn=ou\=Roles,ou\=SomeOrgUnit,o\=mycompany.com
> :group-search-filter=member\=%d:group-target=cn:search-bind-dn=cn\=adminuser,ou\=Users,ou\=SomeOrgUnit,o\=mycompany.com
> :search-bind-password=${ALIAS=ldaprealm-password}"
> "MyRealm"
>
> I did run into some troubles with equals signs (as you might expect),
> but a combination of backslashes and quoting solved the problem (as
> you also might expect :-)). In reality, I can't remember whether the
> --property option was quoted with single quotes or double quotes; I
> believe that actually as I have it written above there's still going
> to be a case where the shell wants to jump in and try to expand
> ${ALIAS=ldaprealm-password} in some way; I may be missing a backslash
> or two above. (This formulation above is the only record I have of a
> series of attempts I made.)
>
> I tried and experience the same thing as you are seeing.
> I notice that even though the console is passing in
> ${ALIAS=the-alias-name-i-choose} to the backend to create the
> realm, it is written out to domain.xml with the value decoded.
>
>
> Oh, I didn't even check that...
>
> {time passes}
>
> ...yep; here too.
>
> I am seeing this in domain.xml after the creation:
>
> classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
>
>
> **
>
>
>
>
> Yes.
>
> Please file a bug on this. create-auth-realm command should not
> decode and write out the password in plain text in domain.xml when
> user is using a password alias.
>
>
> Good; I didn't think so. Bug filed:
> http://java.net/jira/browse/GLASSFISH-18557
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>

ljnelson
Offline
Joined: 2003-08-04

On Mon, Mar 26, 2012 at 9:04 AM, Nithya Subramanian <
> wrote:

> **
> This was an issue which was fixed recently (on Feb 3). The aliases should
> work with the create-auth-realm commands in the latest builds.
>

Great; thank you! I assume "latest builds" means 4.0.x. Any chance of this
being backported to the 3.1.x line?

Best,
Laird

--
http://about.me/lairdnelson