[GLASSFISH-14797] Realm: error when adding a user to a realm in a new config Created: 18/Nov/10  Updated: 17/Feb/11  Due: 04/Feb/11  Resolved: 02/Feb/11

Status: Closed
Project: glassfish
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1_b41

Type: Bug Priority: Blocker
Reporter: shaline Assignee: Jason Lee
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File 14797-2.diff     File 14797.diff    
Issue Links:
Dependency
depends on GLASSFISH-14860 create-file-user should allow specify... Reopened
Duplicate
is duplicated by GLASSFISH-15821 c1-config/Security/Realms/file, Creat... Resolved
Issuezilla Id: 14,797
Tags: 3_1-verified

 Description   

build used : GF V3.1 nightly dated 11/18

Create a new config by copying from default-config.
create a new file realm under new-config/security/realms node.
Select the new file realm and click "Manage Users" button.
We see an error as below:
"File realm new-realm does not exist"

server.log has the below error:
[#|2010-11-18T19:47:09.370-0800|INFO|glassfish3.1|javax.enterprise.system.core.s
ecurity.com.sun.enterprise.security.auth.realm|_ThreadID=15;_ThreadName=Thread-1
;|SEC1115: Realm [new-realm] of classtype [com.sun.enterprise.security.auth.
realm.file.FileRealm] successfully created.|#]

[#|2010-11-18T19:47:14.168-0800|SEVERE|glassfish3.1|org.glassfish.admingui|_Thre
adID=15;_ThreadName=Thread-1;|RestResponse.getResponse() failed. endpoint = 'ht
tp://localhost:4848/management/domain/configs/config/new-config/security-service
/auth-realm/new-realm/list-users'; attrs = '{}'; RestResponse:

{"message":"F ile realm new-realm does not exist","command":"list-file-users AdminCommand" ,"exit_code":"FAILURE"}

"|#]

[#|2010-11-18T19:47:14.189-0800|INFO|glassfish3.1|null|_ThreadID=15;_ThreadName=
Thread-1;|***** users = |#]



 Comments   
Comment by srinik76 [ 28/Nov/10 ]

The error happens in the REST GUI Interface also. REST URL is mentioned in the server log attached as part of bug description

Comment by Jason Lee [ 01/Dec/10 ]

Fix committed (r43284)

Comment by shaline [ 27/Jan/11 ]

This issue exists in promoted b39.
Create a config by copying from default-config.
Create standalone instance referring this config, and start the instance. ( this issue can be seen only when the instance is running).
--Under the new-config/security/Realms/ create a new file realm. --Provide the keyfile as $

{com.sun.aas.instanceRoot}

/config/keyfile
--Select the created keyfile and try to add a user using "Manage Users" button.
Add username, password. click OK.
The below Error gets displayed in the console.

"An error has occurred
Check server log for more information."

Server.log does not have exceptions, but the below message us seen:
[#|2011-01-27T12:56:37.908-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=87;_ThreadName=Thread-;|SEC1115: Realm [file] of classtype [com.sun.enterprise.security.auth.realm.file.FileRealm] successfully created.|#]

[#|2011-01-27T12:56:37.924-0800|INFO|oracle-glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=87;_ThreadName=Thread-;|SEC1117: Realm [file] successfully updated.|#]

[#|2011-01-27T12:56:38.000-0800|SEVERE|oracle-glassfish3.1|org.glassfish.admingui|_ThreadID=21;_ThreadName=Thread-1;|Add user failed. parent=http://localhost:4
848/management/domain/configs/config/local-config/security-service/auth-realm/file/create-user?target=local-config; attrs =

{userpassword=adminadmin, use rname=newadmin, target=local-config, authrealmname=file, groups=[]}

|#]

Comment by Anissa Lam [ 27/Jan/11 ]

As you mentioned, this occurs only when the instance is running. There maybe some restriction for running server, i am not sure. But there has been discussion about user in fileRealm.
I see that we are passing info correctly to backend.
Requesting Kumar to evaluate.

Comment by shaline [ 27/Jan/11 ]

The User actually gets created even with the Error shown above. Select the new file realm in the left tree node, and click the manage Users button. Notice that the user is created.
When we try to delete the created user , we get the below error in GUI Console.
An error has occurred
DELETE http://localhost:4848/management/domain/configs/config/remote-ins-config/security-service/auth-realm/newfilerealm/delete-user?target=remote-ins-config&name=user1 returned a response status of 500

server.log has the below message:

[#|2011-01-27T17:05:49.445-0800|INFO|oracle-glassfish3.1|org.glassfish.admingui|
_ThreadID=31;_ThreadName=Thread-1;|Exception Occurred :DELETE http://localhost:4
848/management/domain/configs/config/remote-ins-config/security-service/
auth-realm/newfilerealm/delete-user?target=remote-ins-config&name=user1 returned a response status of 500|#]

Comment by Anissa Lam [ 27/Jan/11 ]

Here is what i tried.

  • create-instance
  • create- new file realm
  • add user1 to this new realm. FINE, no exception.
  • delete user2 ERROR in server.log
    [#|2011-01-27T17:51:19.298-0800|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=23;_ThreadName=admin-thread-pool-4848(5);|Exception Occurred :DELETE http://localhost:4848/management/domain/configs/config/ABC-config/security-service/auth-realm/test/delete-user?target=ABC-config&name=user2 returned a response status of 500|#]

Again, the user is deleted. even though there is error.
The code is the same whether the server is running or not. I checked what we passed in is correct.
So, I still believe this is a security bug.

Comment by kumarjayanti [ 27/Jan/11 ]

someone please give me the exact steps : full details of the commands. Or should i use GUI to reproduce this ?. Has you tried to reproduce this problem with CLI ?.

Comment by Anissa Lam [ 27/Jan/11 ]

I don't see the problem when using CLI. However, I also see that the correct info is passed in. It will be nice if you can look at your end to see what maybe the problem.
I remember there are issues where CLI/GUI behaves differently and that is expected, like keyfile doesn't exist case.
I have put in the steps in the above comment, here it is again. Please use GUI for these steps.

1. create a standalone instance, with the default provided.
Instance name: ABC
Node: localhost-domain1
Configuration: default-config, select Copy.

2. go to ABC-config -> Security -> Realms
create a file realm, newRealm, specifying $

{com.sun.aas.instanceRoot}

/config/keyfile as the KeyFile

3. Add a user to this newRealm
So far no issue.

4. go to Standalone Instances tree node. Start the ABC instance

5. go to ABC-config -> Security -> Realms -> newRealm
click Manage User and create a new user.
You will see error, with the SEVERE error logged. But the user is created.

6. Now, try to delete this new user. Again, you will see error deleting, but the user is actually deleted.

Note that all these error occurs ONLY when the instance is running.

Thanks for looking into this.

Comment by kumarjayanti [ 27/Jan/11 ]

Ok here are my observations....

1. as shaline points out the GUI reports errors only when the instance is UP and running. When the instance is not running this is not an issue.

2. i goto new-realm under new-config (with instance running) and say manage-users and create a user test.

GUI : An error has occured, check sever.log for more inof

DAS Server.log :
-------

[#|2011-01-28T09:53:56.779+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=65;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T09:53:56.798+0530|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=32;_ThreadName=Thread-1;|Add user failed. parent=http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/create-user?target=new-config; attrs =

{userpassword=test, username=test, target=new-config, authrealmname=new-realm, groups=[]}

|#]
----------

Instance In1 log :
------------
Nothing...
--------------

cat keyfile : (test user is there and this matches the backend log on DAS above)
test;

{SSHA256}

8m3So6x/nS+eZjP2uMO3sL/RjNvWFnJR65p2kwOe8WbUFGPzaJ9E7A==;

3. In GUI go back to Realms under new-config. Select new-realm again and click manage-users
The user test appears correctly there.

4. In GUI delete the user test now:

GUI : An error has occurred
DELETE http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/delete-user?target=new-config&name=test returned a response status of 500

DAS server.log :
-------------

[#|2011-01-28T10:00:04.391+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=99;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:00:04.417+0530|INFO|glassfish3.1|org.glassfish.admingui|_ThreadID=29;_ThreadName=Thread-1;|Exception Occurred :DELETE http://localhost:4848/management/domain/configs/config/new-config/security-service/auth-realm/new-realm/delete-user?target=new-config&name=test returned a response status of 500|#]
-------------

Instance in1 sever.log :
-------------
Nothing..
-------------

cat keyfile : (user test is gone from the backend)
<EMPTY>

5. In GUI go back to Realms under new-config, select new-realm again and click manage-users
GUI : the user test is no longer present its gone.

So how can this be a backend security error ?.

I tried CLI commands for the same and here is the output (with instance in1 running) :

./asadmin create-file-user --target new-config --authrealmname new-realm test1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

./asadmin list-file-users --authrealmname new-realm new-config
test1
Command list-file-users executed successfully.

./asadmin delete-file-user --target new-config --authrealmname new-realm test1
Command delete-file-user executed successfully.

./asadmin list-file-users --authrealmname new-realm new-config
Command list-file-users executed successfully.

And the server.log shows no backend errors :

DAS Server.log
------------
[#|2011-01-28T10:04:21.070+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=65;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:04:39.378+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=98;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]
------------

Instance in1 server.log
-------------
[#|2011-01-28T10:04:21.092+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=64;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]

[#|2011-01-28T10:04:39.435+0530|INFO|glassfish3.1|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=62;_ThreadName=Thread-1;|SEC1117: Realm [new-realm] successfully updated.|#]
-------------

Comment by Anissa Lam [ 27/Jan/11 ]

Thanks. Its just we had problem before regarding creating user and CLI and GUI behaves differently, so would like you to double check.

Assign to Jason to see why we are getting error when backend is fine.

Comment by kumarjayanti [ 27/Jan/11 ]

In Summary : if we go back in the GUI by selecting the Realms (under new-config) on the left-pane and then select new-realm and click on manage-users, it shows the right values. And not something erroneous/random. If the previous operation was to create the user "test" then it would show the user "test" and if the previous operation was to delete the user "test" it would show that there are no more users.

So it is clear to me that this is not a backend error.

It also appears to me that the GUI is executing the right command at the backend. However i see one difference. When i excecute the commands CLI, the command seems to have been replicated in the instance in1 log. However when doing the same operations from GUI Nothing ever appears in the instance in1 logs. Not sure why this difference.

Comment by kumarjayanti [ 27/Jan/11 ]

I tried to see if there is some interference with the shared domains/domain1/config/keyfile and so i changed the keyfile for new-realm to point to /tmp/keyfile and created the file.

Then repeated the same steps and it shows the same behavior as before.

Comment by kumara [ 27/Jan/11 ]

When you fix this, please be sure to remove printing of password from the log message. Passwords must not be written to log files in clear.

Comment by Jason Lee [ 31/Jan/11 ]

I don't think is a REST or Console issue. When the Console issues the REST request to create the user, ultimately, create-file-user is called (the actual call is at ResourceUtil.java:202, though the params are set up earlier in the call stack):

CommandRunner cr = habitat.getComponent(CommandRunner.class);
RestActionReporter ar = new RestActionReporter();

cr.getCommandInvocation(commandName, ar).parameters(parameters).execute();
return ar;

commandName = "create-file-user"
parameters =

{username: [user2] userpassword: [user2] target: [in1-config] authrealmname: [newRealm] }

The topMessage in the ActionReporter says "An error occurred during replication" and the exitCode is "FAILURE". This looks like a backend issue to me. I don't know why we don't see this from the command line (even with AS_DEBUG set to true), but the AdminCommand is clearly returning an error condition to the REST layer, which we dutifully relay. It's possible, I guess, that the console is sending bad/incorrect data, but rebuilding the CLI command from the data above works, so I'd be surprised to see that be the case.

Comment by Jason Lee [ 01/Feb/11 ]

Reassigning to security to evaluate the issue documented above.

Comment by kumarjayanti [ 02/Feb/11 ]

The bug is marked a blocker because you are logging passwords when the exception occurs. Abhijit noticed this. So you should fix that, and in the mean time nithya will try to debug the issue. Please reassign to us after you fix the logging issue.

Comment by kumarjayanti [ 02/Feb/11 ]

Nithya has debugged with debugger breakpoints today and it is clear that the command replication is failing. The command never reaches the instance for execution when the GUI path is used. However when the same thing is run by CLI command-line the debugger breakpoint is hit on the instance.

So it appears the Replication API is being invoked incorrectly by the REST Service code.

---------
This also confirms my observation (posted : 27/Jan/11 08:54 PM) : However i see one difference. When i excecute the commands CLI, the command seems to have been replicated in the instance in1 log. However when doing the same operations from GUI Nothing ever appears in the instance in1 logs. Not sure why this difference.
---------

Comment by Jason Lee [ 02/Feb/11 ]

This seems to be a GUI issue. Changing component and reclaiming ownership. Fix and dev test coming shortly for review.

Comment by Jason Lee [ 02/Feb/11 ]

Thanks to Tom, I think we've tracked this down to a Console issue. Fix (and test) attached.

How bad is its impact? (Severity)
Moderate. Administrators are unable to add new users to realms associated with standalone instances (or clusters, I would guess).

How often does it happen? (Frequency)
Every time

How much effort is required to fix it? (Cost)
Moderate. Most of the time was spent in diagnosing. The actual fix is very simple.

What is the risk of fixing it? (Risk)
Very little, as this affects just this one page.

Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes. The CLI works as expected.

If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
Yes.

How long has the bug existed in the product?
Unknown, but quite likely for quite some time.

Do regression tests exist for this issue?

Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
GUI Dev Tests

When will a tested fix be ready for integration?
The fix is in a diff attached to this issue. The patch also contains a new test to catch regressions.

Comment by Anissa Lam [ 02/Feb/11 ]

========
In line# 370:
RestResponse response = RestUtil.delete(endpoint, attrs);

I see that RestUtil.delete() is calling
checkStatusForSuccess(cr);
which throws RuntimeException unless it succeeds. So, you will never get to the next if() statement.
You probably need to catch that exception.
(Ideally, Everything should really go through RestUtil.restRequest() which parse the response, and return failure/Warning. But we don't want to change that now.)

==============

Sounds like you remove the authrealmname in the original code, but when you add it back, it is commented out.
Is this the intend ?

+// attrs.put("authrealmname", realmName);

Comment by Jason Lee [ 02/Feb/11 ]

That commented out line actually needs to be removed. REST adds that based on the URL.

WRT to RestUtil.delete(), I have no comment on that. The only reason there's a change there is that NetBeans cleaned up the logging code, a change we can probably live without.

Comment by Anissa Lam [ 02/Feb/11 ]

I still prefer catching the Exception in the delete() case, otherwise,GUI screen will be messed up with exception showing, if there is any error in the deletion.

Please add the comment that REST adds authRealmName and we shouldn't specify it in the code.

Comment by Jason Lee [ 02/Feb/11 ]

I've attached another patch with some cleanups.

Comment by Anissa Lam [ 02/Feb/11 ]

ok. change looks good, although you didn't add the comment
thanks.

Comment by Chris Kasso [ 02/Feb/11 ]

Approved for RC2.

Comment by Jason Lee [ 02/Feb/11 ]

I forgot about that part. If we add it here, though, we'd probably need to make similar comments on every other REST endpoint to be consistent, right? I don't think sending it is a problem, but it's unnecessary, so I cleaned it up.

Comment by Jason Lee [ 02/Feb/11 ]

Fix committed to trunk (r44835) and branch (r44836).

Comment by shaline [ 17/Feb/11 ]

Verified in promoted b43.

Generated at Tue Aug 30 18:13:30 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.