Issue Details (XML | Word | Printable)

Key: GLASSFISH-14797
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Jason Lee
Reporter: shaline
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
glassfish

Realm: error when adding a user to a realm in a new config

Created: 18/Nov/10 07:56 PM   Updated: 17/Feb/11 01:56 PM  Due: 04/Feb/11   Resolved: 02/Feb/11 03:48 PM
Component/s: admin_gui
Affects Version/s: 3.1_b41
Fix Version/s: 3.1_b41

Time Tracking:
Not Specified

File Attachments: 1. File 14797-2.diff (9 kB) 02/Feb/11 03:32 PM - Jason Lee
2. File 14797.diff (8 kB) 02/Feb/11 02:33 PM - Jason Lee

Environment:

Operating System: All
Platform: All

Issue Links:
Dependency
 
Duplicate
 

Issuezilla Id: 14,797
Tags: 3_1-verified
Participants: Anissa Lam, Chris Kasso, Jason Lee, kumara, kumarjayanti, shaline, shaline and srinik76


 Description  « Hide

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 = |#]



srinik76 added a comment - 28/Nov/10 10:42 PM

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


Jason Lee added a comment - 01/Dec/10 10:27 AM

Fix committed (r43284)


shaline added a comment - 27/Jan/11 01:00 PM

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=[]}|#]


Anissa Lam added a comment - 27/Jan/11 02:32 PM

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.


shaline added a comment - 27/Jan/11 05:28 PM

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|#]


Anissa Lam added a comment - 27/Jan/11 06:00 PM

Here is what i tried.

  • create-instance
  • create- new file realm
  • add user1 to this new realm. FINE, no exception.
  • start-instance
  • add user2 to the new realm again. ERROR in server.log
    [#|2011-01-27T17:50:58.602-0800|SEVERE|glassfish3.1|org.glassfish.admingui|_ThreadID=29;_ThreadName=admin-thread-pool-4848(8);|Add user failed. parent=http://localhost:4848/management/domain/configs/config/ABC-config/security-service/auth-realm/test/create-user?target=ABC-config; attrs ={userpassword=abcd, username=user2, target=ABC-config, authrealmname=test, groups=[]}|#]
  • 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.


kumarjayanti added a comment - 27/Jan/11 08:01 PM

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 ?.


Anissa Lam added a comment - 27/Jan/11 08:29 PM

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.


kumarjayanti added a comment - 27/Jan/11 08:40 PM

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.|#]
-------------


Anissa Lam added a comment - 27/Jan/11 08:54 PM

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.


kumarjayanti added a comment - 27/Jan/11 08:54 PM

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.


kumarjayanti added a comment - 27/Jan/11 09:00 PM

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.


kumara added a comment - 27/Jan/11 09:16 PM

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.


Jason Lee added a comment - 31/Jan/11 02:53 PM

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.


Jason Lee added a comment - 01/Feb/11 10:51 AM

Reassigning to security to evaluate the issue documented above.


kumarjayanti added a comment - 02/Feb/11 12:04 AM

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.


kumarjayanti added a comment - 02/Feb/11 05:45 AM

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.
---------


Jason Lee added a comment - 02/Feb/11 01:11 PM

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


Jason Lee added a comment - 02/Feb/11 02:36 PM

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.


Anissa Lam added a comment - 02/Feb/11 02:56 PM

========
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);


Jason Lee added a comment - 02/Feb/11 02:59 PM

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.


Anissa Lam added a comment - 02/Feb/11 03:10 PM

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.


Jason Lee added a comment - 02/Feb/11 03:32 PM

I've attached another patch with some cleanups.


Anissa Lam added a comment - 02/Feb/11 03:39 PM

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


Chris Kasso added a comment - 02/Feb/11 03:43 PM

Approved for RC2.


Jason Lee added a comment - 02/Feb/11 03:43 PM

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.


Jason Lee added a comment - 02/Feb/11 03:48 PM

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


shaline added a comment - 17/Feb/11 01:56 PM

Verified in promoted b43.