[GLASSFISH-11416] When deploying jruby apps using the jruby deployer, no granted.policy is generated to set app-specific permissions Created: 09/Jan/10  Updated: 04/Oct/10

Status: Open
Project: glassfish
Component/s: jruby
Affects Version/s: V3
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: bluescreen303 Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 11,416
Tags: 3_1-exclude

 Description   

1) I want to run multiple jruby applications on 1 domain.
2) I want to use glassfish v3's directory/jruby container based deployment
instead of creating a .war file.
3) I don't want the applications to be able to read/write each other's
sourcecode in case 1 application gets hacked.
4) I also want to be able to deploy new applications (with their own policy)
without having to restart the domain (which will take down all apps for a few
seconds).

Since server.policy changes require the domain to restart (breaking 4), I would
like to use domains/domain1/generated/policy/myapp/granted.policy
It appear this file is not generated/available for applications deployed using
the jruby container.

This forces me to either deploy the old way, or leave my apps insecure, or have
domain-restarts affecting other apps.

I think it would be nice if the jruby container based deployment would behave
like other containers regarding security (policy generation).

Now I don't know if this defect should be fixed by the security team or by the
jruby container developers, so I just picked 1.

Thanks for any feedback/fixes/workarounds in the meantime.
Mathijs



 Comments   
Comment by bluescreen303 [ 11/Jan/10 ]

to clearify myself a bit:

I'm only talking about filesystem permissions.
Since ruby apps are scripts, they are just plain text files.
Default glassfish install (even with security manager on) is to allow all
read/writes to all files/dirs. This will allow 1 hacked/bad app to change other
apps code/config, which makes it easy to disable security checks in them so they
can get hacked too.
Since glassfish (+ all apps) run under the same (os) user, I can't protect
against this by just changing file access permissions on the OS level.
Also, since (looking from java) the codeBase is jruby-home (and not the
directory containing the ruby source files), it's impossible to set different
policies for different apps using server.policy.
This means I need to use per-app policy files or leave all apps open to the
attack mentioned above.

This means that for now I still need to use .war based deployment, where per
app granted.policy is available, but complicating lots of things (migrations,
user uploads) that the ruby container was good for.

Comment by kumarjayanti [ 04/Oct/10 ]

There needs a discussion between security team and jruby container team to see how to solve this.





[GLASSFISH-15429] Modifying keyfile path in a newly created config does not properly list the users Created: 04/Jan/11  Updated: 16/Nov/11

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1_ms07
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: srinik76 Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15406 Unable to edit custom admin-realm in ... Closed
Tags: 3_1-exclude, 3_1-next, 3_1-release-note-added, 3_1-release-notes, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

1. asadmin copy-config default-config new-config
2. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
3. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
4. file /tmp/v3/admin-keyfile is not currently created.
5. asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
6. cat /tmp/v3/admin-keyfile
test;

{SSHA256}mjyhJFWxU8xUnGMY5bt+ngwj3tf6v6yOTKB7DgGKJUu6Neky/GVOsQ==;asadmin
user1;{SSHA256}

rImtlHJuqi6AMSypIUyBdcs2CUEPQq3pIEHSEsndYQmhBl4ZBT+fJA==;user1
<user test is properly added to admin-keyfile under /tmp/v3 as expected.>
8. asadmin list-file-users --authrealmname admin-realm new-config
user1
Command list-file-users executed successfully.
<Expected is test,user1 but it lists user1 which it takes from $

{instance_root}

/domains/domain1/config/keyfile but it should list from /tmp/v3/admin-keyfile>

The list-file-users needs to be fixed to list from /tmp/v3/admin-keyfile



 Comments   
Comment by kumarjayanti [ 04/Jan/11 ]

Srini,

Either there is no bug or you have not given me the complete set of steps. With the steps that you provided it is not clear how the user :"user1" is already present in the /tmp/v3/admin-keyfile.

Also are you using the latest builds. Here are the steps that i executed and i see no problems

1.)

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Documents/workspace/glassfish/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

2.)
$ ./asadmin copy-config default-config new-config

Command copy-config executed successfully.

3)
$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.

4)
$ mkdir /tmp/v3
$ > /tmp/v3/admin-keyfile

5)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

6)
$ cat /tmp/v3/admin-keyfile
test;

{SSHA256}

H0J8mMtMJp1BcPynsBqyDw8r0WWI30796BaFrsdmei3eBh3YDILKKg==;asadmin

7)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
Command list-file-users executed successfully.

8)
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config user1
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.

9)
$ ./asadmin list-file-users --authrealmname admin-realm new-config
test
user1
Command list-file-users executed successfully.

Comment by kumarjayanti [ 04/Jan/11 ]

Cannot reproduce. Make sure you are using the very latest glassfish build. And please provide the exact steps to reproduce.

I will try some other combination in the meantime to see if i can reproduce anything like what u mention.

Comment by srinik76 [ 04/Jan/11 ]

I have not created the file. As per the requirement do we need to create the file.

If not created we see this problem.

Comment by kumarjayanti [ 04/Jan/11 ]

The Keyfile needs to be created physically and ideally this should be done before even the set command is executed to change the keyfile property.

That said, if the keyfile is not created then when i test purely from CLI i do not get the problem you see. I see the create-file-user fails.

Comment by Anissa Lam [ 04/Jan/11 ]

It is the responsibility of the user to create the keyfile ( I hope the documentation specifies that) or the security code should be smart enough to detect that the keyfile doesn't exist and create that for the user.
GUI should NOT create the keyfile.

As commented in GLASSFISH-15406, there is error given if the keyfile doesn't exist.
$ ./asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed.
Command create-file-user failed.

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

Comment by srinik76 [ 04/Jan/11 ]

Tested with the latest build, create-file-user fails with following message

asadmin create-file-user --authrealmname admin-realm --target new-config test
Enter the user password>
Enter the user password again>
remote failure: Adding User test to file realm admin-realm failed. /tmp/v3/admin-keyfile (No such file or directory)
/tmp/v3/admin-keyfile (No such file or directory)

list-file-users also should report that /tmp/v3/admin-keyfile is not found, but it lists the user (admin)

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

Comment by kumarjayanti [ 05/Jan/11 ]

Anissa Said :
----------

GUI should show the error to the user.
However, there is no reason given to the user WHY the creation failed. It should tell user that the keyfile doesn't exist. Thus I am re-opening this bug but downgrading it. The error message needs to be clear.

--------

I checked the code and the CLI command tried to do the following :
report.setMessage(
localStrings.getLocalString("create.file.user.useraddfailed",
"Adding User

{0}

to the file realm

{1}

failed",
userName, authRealmName) + " " + localalizedErrorMsg);
report.setActionExitCode(ActionReport.ExitCode.FAILURE);
report.setFailureCause(e);

It appears when the Message is set it takes priority over setFailureCause in the admin framework. I can remove the setMessage for the next release. Or if you think it is important for you since this message has to be displayed in the GUI then please reopen the bug and i will ask for approval.

I see a similar problem with list-file-users as well where it sets all the 3 items on the report object and hence the message that was set takes priority and that message is currently not very good.

I can fix both of them as part of this. The question is would you like messages fixed for V3.1.

Comment by srinik76 [ 05/Jan/11 ]

Reopening issue after discussing with kumar.

Now from the security side it will check for the keyfile existence while listing file users.

Comment by kumarjayanti [ 05/Jan/11 ]

1) How bad is its impact? (Severity)
While we are unable to reproduce it by pure CLI operations it appears GUI seems to observe some incorrect file-user listing in this case. Also the message log for the Failure can be improved to indicate the real cause.

2) How often does it happen? (Frequency)
This will occur only when keyfile of a file-realm points to a non-existent File.

3) How much effort is required to fix it? (Cost)
Minor : the fix is to add a check for non-existent keyfile and throw an error.

4) What is the risk of fixing it? (Risk)

None (does not affect the Runtime). GUI wants these enhancements.

Comment by Anissa Lam [ 05/Jan/11 ]

Approved.

Comment by kumarjayanti [ 05/Jan/11 ]

fixed

Comment by srinik76 [ 05/Jan/11 ]

Fix works fine, but when the key file is created

list-file-users should report none, but lists admin user.

Waiting for comments from kumar to reopen the issue.

Comment by srinik76 [ 06/Jan/11 ]

After changing the key file and restarting the server, it works fine.

Comment by srinik76 [ 06/Jan/11 ]

Comments from Kumar in email

Hi Srini, Anissa,

I think i understand what is happening.

1. default-config is copied as new-config
2. Now the admin-realm is selected in the GUI from this new-config
3. Its KeyFile property is changed to some XYZ and the change is saved. Using an asadmin set-command
4. A physical XYZ file is created
5. Now again ManageUsers is clicked on the admin-realm of new-config
5.1. At this time ListFileUsers command still shows the original admin user that is part of the admin-realm in default-config

Is this a correct description of the issue ?. If that is true then yes that can happen.

1. Step 2 loads the admin-realm in the Backend.
2. Setp 3 modifies the property of the realm in the Config-Layer
3. Backend is not informed of this change. And since the new-config is not the running config of the Server (DAS) the ConfigListener Mechanism (which is in place) does not come into picture. So the backend realm is never updated.
4. ListFileUsers command which executes as part of step (5) above does a refresh of the keyfile contents but it never goes back to the config-layer to see if the keyfile has changed. And it does not make sense for ListFileUsers to do that (checking for changes to the realm definition in config-layer). Things would have worked if it did that but really the syncing between Config-Layer and Backend should have happened when step (3) above invoked the "asadmin set" command to modify the keyfile property.

There are 4 solutions :

1. I can provide a new hidden command which has to be executed by GUI whenever they do a asadmin set on any realm (and file-realm in particular). This command would then try to sync the Config change made by the set to the backend. For some realms this inplace update cannot be performed for-example

  • if it is an LDAPRealm of the active server config and there are applications currently using that realm and the set command tries to modify the URL of the LDAP server or the base-dn of the LDAPRealm. Such changes will require a RESTART of the Application Server.

2. Fix ListFileUsers to re-read the config-layer. Not a good idea and not the right fix.

3. GUI can indicate after the set-command that Appserver should be restarted.

4. GUI should not use an asadmin set to modify the keyfile location. Instead it should delete the existing Realm and create a New Realm with modified properties.

Let me know which approach would be best for V3.1.

regards,
kumar

Waiting for Anissa's comments to decide what approach (1 out of 4 suggested by kumar) to be taken for the solution.
Anissa/Kumar, Can I reopen the bug?

Comment by kumarjayanti [ 06/Jan/11 ]

I am also not sure if a Property change in realm (using asadmin set) in an active server config will cause the Config Change Event which can be received by a registered ConfigListener.

Comment by Anissa Lam [ 06/Jan/11 ]

As i understand it, only GUI user sees this problem. CLI user will not have such an issue. Correct me if i am wrong. But i just tried using CLI to do all the steps and list-file-user reports the correct list.
So, what exactly is missing in GUI code, compared to CLI, that causes this error in GUI only ? I want to understand this, and that maybe how we should fix it.

The corresponding steps in CLI works perfectly fine, and list-file-user is reporting the list of users from the new key file correctly.

~ 1) asadmin copy-config default-config TEST-config
Command copy-config executed successfully.
~ 2)
~ 2) asadmin list-file-users --authrealmname admin-realm server-config
admin
Command list-file-users executed successfully.
~ 3)
~ 3)
~ 3) asadmin get configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
Command get executed successfully.
~ 4)
~ 4) asadmin set configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
configs.config.TEST-config.security-service.auth-realm.admin-realm.property.file=/tmp/keyFile
Command set executed successfully.
~ 5)
~ 5)
~ 5) touch /tmp/keyFile
~ 6)
~ 6) asadmin list-file-users --authrealmname admin-realm TEST-config
Command list-file-users executed successfully.
~ 7)
~ 7)

Comment by Anissa Lam [ 06/Jan/11 ]

Re-open issue as this is still under active discussion and GUI depends on the fix.

Comment by kumarjayanti [ 06/Jan/11 ]

Your step two :
~ 2) asadmin list-file-users --authrealmname admin-realm server-config

should be changed to

2) asadmin list-file-users --authrealmname admin-realm TEST-config

and IMO that will reproduce the problem in CLI

Comment by kumarjayanti [ 06/Jan/11 ]

I retested after implementing solution 1. Here is the output :

$ ./asadmin start-domain
Waiting for domain1 to start ..........
Successfully started the domain : domain1
domain Location: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1
Log File: /Users/vbkumarjayanti/Downloads/glassfish3/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.

$ ./asadmin copy-config default-config new-config
Command copy-config executed successfully.

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

$ ./asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname admin-realm new-config
Synchronization of Realm admin-realm from Configuration Successful.
Command __synchronize-realm-from-config executed successfully.

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

$ cat /tmp/mykeyfile

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

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

Comment by kumarjayanti [ 06/Jan/11 ]

The new hidden command will set RESTART required if the change was done to an active server config

$ ./asadmin set server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
server-config.security-service.auth-realm.file.property.file=/tmp/mykeyfile
Command set executed successfully.

$ ./asadmin __synchronize-realm-from-config --realmname file server-config
Restart required for configuration updates to active server realm: file.
Command __synchronize-realm-from-config executed successfully.

And here is how the code in the command sets the information required for GUI for a restart. I picked up this code from :

core/kernel/src/main/java/com/sun/enterprise/v3/admin/GetRestartRequiredCommand.java

private void setRestartRequired(ActionReport report) {
report.setActionExitCode(ActionReport.ExitCode.SUCCESS);
ActionReport.MessagePart mp = report.getTopMessagePart();

Properties extraProperties = new Properties();
Map<String, Object> entity = new HashMap<String, Object>();
mp.setMessage(_localStrings.getLocalString("RESTART_REQUIRED",
"Restart required for configuration updates to active server realm:

{0}

.",
new Object[]

{realmName}

));
entity.put("restartRequired","true");
extraProperties.put("entity", entity);
((ActionReport) report).setExtraProperties(extraProperties);
}

Comment by kumarjayanti [ 06/Jan/11 ]

checked in the Partial Fix which will make the GUI work.

GUI has to invoke the new hidden command whenever an asadmin set is invoked on any realm.

The CLI this bug still remains if someone does the following sequence of operations :

1. asadmin copy-config default-config new-config
2. asadmin list-file-users --authrealmname admin-realm new-config
admin
Command list-file-users executed successfully.
3. asadmin get new-config.security-service.auth-realm.admin-realm.property.file
new-config.security-service.auth-realm.admin-realm.property.file=$

{com.sun.aas.instanceRoot}

/config/admin-keyfile
4. asadmin set new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
new-config.security-service.auth-realm.admin-realm.property.file=/tmp/v3/admin-keyfile
Command set executed successfully.
5. create the physical keyfile at /tmp/v3/admin-keyfile

After doing these steps, the following command will give a wrong answer :

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

This is because the asadmin set command in step-4 above updates the Configuration Layer but does not update the Backend Realm which was loaded while executing step 2. So the list command will continue to list the user admin which was present in the original realm's keyfile (one that it was referring to before the set command changed it).

Summary of the CLI Bug : If an asadmin set command is executed to change a realm-property for a realm that was loaded by the backend (due to an earlier CLI command targeted at the realm) , then the realm continues to behave as if the set command was not executed. The workaround is to restart Appserver after a set command has been used to change a property of an already loaded realm.

Comment by Scott Fordin [ 15/Apr/11 ]

Issue added to 3.1 Release Notes.





[GLASSFISH-4271] Unified JSR 196 Security Created: 27/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: haroldcarr Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,271
Status Whiteboard:

v3-prd-item


 Description   

GF v3 PRD



 Comments   
Comment by haroldcarr [ 27/Feb/08 ]

Added v3-prd-item in status whiteboard

Comment by kumarjayanti [ 03/Sep/09 ]

Fixed.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-4270] Kerberos interoperability with .NET 3.5 Created: 27/Feb/08  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: web_services
Affects Version/s: V3
Fix Version/s: not determined

Type: New Feature Priority: Major
Reporter: haroldcarr Assignee: kumarjayanti
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 4,270
Status Whiteboard:

v3-prd-item


 Description   

GF V3 PRD



 Comments   
Comment by haroldcarr [ 27/Feb/08 ]

Added v3-prd-item in status whiteboard

Comment by haroldcarr [ 27/Feb/08 ]

Change to FEATURE

Comment by ido_ran [ 13/Jun/09 ]
      • Issue 4270 has been confirmed by votes. ***
Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.





[GLASSFISH-16473] Introduce a default CertStore in GlassFish that can be used by JSR196 CertStoreCallback Created: 27/Apr/11  Updated: 18/Oct/12

Status: Open
Project: glassfish
Component/s: security
Affects Version/s: 4.0
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: kumarjayanti Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ee7ri_cleanup_deferred

 Description   

In Metro Security there is a usecase which requires that the Server store the Client Certificates and Vice-Versa. In such situations today we store the client certificate in the Server Truststore and similarly the Server Certificate is stored in the Client Truststore. Storing non-CA certificates in TrustStore is not a good idea from a security perspective.

The Java CertStore (http://download.oracle.com/javase/6/docs/api/java/security/cert/CertStore.html) is an appropriate place to store such other-party non-CA certificates. The JSR196 CertStoreCallback in GlassFish however returns the GF truststore as the CertStore.

As a first step we would like to introduce a new keystore in the domain config that will be exposed as a CertStore via the JSR196 Default CallbackHandler in GlassFish. In a later release (if developers really ask for it) we could think of a CertStore configuration element under security-service. That would allow more flexibility on what the CertStore backend really is (for example an LDAP). Today Metro developers have the option of overriding the whole GlassFish JSR-196 CallbackHandler, and this would allow them to have any arbitary CertStore implementation.



 Comments   
Comment by kumarjayanti [ 27/Apr/11 ]

Impact on ADMIN GUI/CLI
----------------------

Since Keystore contents are really not managed by Admin GUI/CLI today so adding a new keystore to the domain config does not cause any impact on Admin.

Impact on Cluster Replication Framework
------------------------------

The Cluster replication framework should apply the same rules for this new keystore (named certstore.jks) as it does for the GF keystore and truststore. IOW, instance config's should have a copy of the certstore.jks. And updates to certstore.jks on the DAS followed by touching domain.xml should cause the updated certstore.jks to be synced to the instances upon cluster restart.

Comment by Tom Mueller [ 18/Oct/12 ]

Marking the fix version field as "future-release". This is based on an evaluation by John, Michael, and Tom WRT to the PRD for the Java EE 7 RI/SDK. This issue was deemed to not be a P1 for that release. If this is in error or there are other reasons why this RFE should be targeted for the Java EE 7 RI/SDK release, then change the fix version field back to an appropriate build.





[GLASSFISH-16587] request.getUserPrincipal() does not return MyPrincipal Created: 09/May/11  Updated: 14/May/15

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1
Fix Version/s: future release

Type: Bug Priority: Major
Reporter: gernot1 Assignee: kumarjayanti
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1-next, 3_1_1-exclude, 3_1_1-scrubbed, 3_1_2-exclude

 Description   

I've an own javax.security.auth.message.module.ServerAuthModule implementation.
In validateRequest() I put an instance of MyPrincipal to the callbackhandler
MyPrincipal myprincipal = ...;
callbackHandler.handle(new Callback[]

{ new CallerPrincipalCallback(clientSubject, myprincipal), new GroupPrincipalCallback(...) }

);
In the application request.getUserPrincipal() returns an instance of com.sun.enterprise.security.web.integration.WebPrincipal and NOT an instance of MyPrincipal!

In an ejb the call of ejbContext.getCallerPrincipal() does return an instance of MyPrincipal!

==> request.getUserPrincipal() should return the principal which is set in the ServerAuthModule



 Comments   
Comment by kumarjayanti [ 09/May/11 ]

yes this is a known issue and we made some work on it to get the behavior you are looking for. It is still not committed, more work to do.

Comment by kumarjayanti [ 18/May/11 ]

We will make an attempt to get this fixed for 3.1.1 but cannot commit based on resources and time left.

Comment by sultry [ 14/May/15 ]

Depends on this bug made that workaround:

private static Principal glassfishWorkAround(HttpServletRequest request) {
        Principal principal = null;
        try {
            Principal webPrincipal = request.getUserPrincipal();
            if (webPrincipal != null) {
                Class glassfishWrapper = Class.forName("com.sun.enterprise.security.web.integration.WebPrincipal");
                if (glassfishWrapper.isInstance(webPrincipal)) {
                    Field customPrincipal = glassfishWrapper.getDeclaredField("customPrincipal");
                    customPrincipal.setAccessible(true);
                    principal = (Principal) customPrincipal.get(webPrincipal);
                } else {
                    principal = webPrincipal;
                }
            }
        } catch (IllegalArgumentException | IllegalAccessException | NoSuchFieldException | SecurityException | ClassNotFoundException ex) {
            LOGGER.throwing("SecurityConstraint", "glassfishWorkAround", ex);
        }
        return principal;
}

public static Principal getPrincipal(HttpServletRequest request) {
        return glassfishWorkAround(request);
}

Hope it helps somebody! Anyway hope this bug will be resolved soon.





[GLASSFISH-14860] create-file-user should allow specifying target Created: 29/Nov/10  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 3.1
Fix Version/s: 4.1

Type: Bug Priority: Minor
Reporter: Anissa Lam Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all platform


Issue Links:
Dependency
blocks GLASSFISH-14797 Realm: error when adding a user to a ... Closed
blocks GLASSFISH-14770 Realm: new user added to admin-realm ... Closed
Tags: 3-1-regression

 Description   

list-file-users , delete-file-user takes in target, but create-file-user doesn't.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username

Without being able to specify the target during creation, it seems this user is created for EVERY instance.
here is what i see:

%asadmin create-file-user --authrealmname file userABC

Command create-file-user executed successfully.

%asadmin list-file-users --authrealmname file server
userABC
Command list-file-users executed successfully.

%asadmin list-file-users --authrealmname file instance-1
userABC
Command list-file-users executed successfully.

Besides missing the target option, list and delete doesn't takes in config name as target.
%asadmin list-file-users --authrealmname file sever-config
org.glassfish.api.admin.CommandException: remote failure: Unable to find a valid target with name sever-config
Command list-file-users failed.
This doesn't sound right since any security realm is based on configuration, so it should take in config name as target as well.

GUI issue (GLASSFISH-14797) and (GLASSFISH-14770) is depending on this bug fix. We want the following to happen:

1. add 'target' as an option for create-file-user (blocks GLASSFISH-14770)
2. config name should be a valid target. (blocks GLASSFISH-14797)



 Comments   
Comment by kumarjayanti [ 30/Nov/10 ]

Note : create-file-user and delete-file-user already support a --target option. It has to be a --target since the username is the operand for these commands and this is not any different from V2.

Added CONFIG as a targetype.

Note : When dealing with create-file-user and delete-file-user you really need to look at what the Property

<property value="$

{com.sun.aas.instanceRoot}

/config/keyfile" name="file" />

is pointing to. For example the same property above appears in default-config and server-config. So if you do

create-file-user with one config and do list-file-users with another config. You might see the new user under the second config if they share the same keyfile. This is not a bug in security.

Comment by kumarjayanti [ 30/Nov/10 ]

fixed

Comment by Anissa Lam [ 18/Dec/10 ]

I have to reopen this issue.
I don't see a target option for create-file-user with the latest nightly build 12/18.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username
Command create-file-user failed.

Comment by Anissa Lam [ 18/Dec/10 ]

Raising the issue. This has to be fixed for 3.1

Comment by kumarjayanti [ 19/Dec/10 ]

------------------
%asadmin list-file-users --authrealmname file sever-config
org.glassfish.api.admin.CommandException: remote failure: Unable to find a valid target with name sever-config
Command list-file-users failed.
This doesn't sound right since any security realm is based on configuration, so it should take in config name as target as well.
-------------------

This command above is giving a bogus config as argument and hence the failure is correct. I think you misspelled server-config as sever-config.

---------here is the output for right config------
./asadmin list-file-users --authrealmname file server-config
test1
test
Command list-file-users executed successfully.
-------------------------------------------

Same issue with delete-file-users

-------------------
$ ./asadmin delete-file-user --authrealmname file --target server-config test1
Command delete-file-user executed successfully.
$ ./asadmin list-file-users --authrealmname file server-config
test
Command list-file-users executed successfully.
--------------------

And create-file-users does accept a --target option :

---------------------------------
$ ./asadmin create-file-user --authrealmname file --target server-config test2
Enter the user password>
Enter the user password again>
Command create-file-user executed successfully.
$ ./asadmin list-file-users --authrealmname file server-config
test2
test
Command list-file-users executed successfully.

----------------------------------

And here is the output of create-file-user --help (it does show the --target option in the help and a config is acceptable as an argument.

$ ./asadmin create-file-user --help

asadmin Utility Subcommands create-file-user(1)

NAME
create-file-user - creates a new file user

SYNOPSIS
create-file-user[--help] [--authrealmname auth_realm_name]
[--target target
[--groups user_groups[:user_groups]*] user_name

DESCRIPTION
Thecreate-file-user subcommand creates an entry in the key-
file with the specified username, password, and groups. Mul-
tiple groups can be created by separating them with a colon
(. If auth_realm_name is not specified, an entry is
created in the keyfile for the default realm. If
auth_realm_name is specified, an entry is created in the
keyfile using the auth_realm_name.

This subcommand is supported in remote mode only.

OPTIONS
--help
-?

Displays the help text for the subcommand.

--target
This is the name of the target on which the command
operates. The valid targets are config, instance, clus-
ter, or server. By default, the target is the server.

This option is valid only in domains that are configured
to support clusters, such as domains that are created
with the cluster profile or the enterprise profile.

--groups

This is the group associated with this file user.

--authrealmname
This is the file where the file users are stored.

OPERANDS
user_name This is the name of file user to
be created.

Java EE 6 Last change: 01 December 2010 1

asadmin Utility Subcommands create-file-user(1)

EXAMPLES
Example 1 Creating a User in the File Realm

This example creates a file realm user named sample_user. It
is assumed that an authentication realm has already been
created using the create-auth-realm subcommand.

asadmin> create-file-user
--groups staff:manager
--authrealmname auth-realm1 sample_user
Command create-file-user executed successfully

EXIT STATUS
0 subcommand executed successfully

1 error in executing the subcom-
mand

SEE ALSO
create-auth-realm(1), delete-file-user(1), list-file-
users(1), update-file-user(1), list-file-groups(1)

Comment by kumarjayanti [ 19/Dec/10 ]

closing the issue as cannot reproduce unless you give me the specific create-file-user command that is failing/refusing to accept a --target.

Comment by Anissa Lam [ 19/Dec/10 ]

ok, man page is correct and include --target.
But usage does NOT have --target as an option. Thats why i was confused.

Please fix the usage text so there is no confusion. I still see issues with creating and listing file user. will file another bug.

Usage: asadmin [asadmin-utility-options] create-file-user
[--groups user_groups[:user_groups]*] [--authrealmname <authrealm_name>]
[?|-help[=<help(default:false)>]] username

Also, since authrealmname is optional, what is the realmname defaults to if not specified. Man page didn't specify that either.

Comment by kumarjayanti [ 19/Dec/10 ]

Where is the usage controlled from and how do you get the usage string ?. Can you tell me the command which prints the usage ?, why is there a separate Usage apart from --help which shows up the manpage. It is not the security code that controls the usage. So please transfer the bug to Docs or Admin.

Here is the usage that we have in comments on top of create-file-user.

/**

  • Create File User Command
  • Usage: create-file-user [--terse=false] [--echo=false] [--interactive=true]
  • [--host localhost] [--port 4848|4849] [--secure | -s]
  • [--user admin_user] [--userpassword admin_passwd]
  • [--passwordfile file_name] [--groups user_groups[:user_groups]*]
  • [--authrealmname authrealm_name] [--target target(Default server)]
  • username
    *
  • @author Nandini Ektare
    */
Comment by Anissa Lam [ 19/Dec/10 ]

Tom,
Can you comment on how to fix the usage of a command ? If this is a trivial fix, maybe we should address that for 3.1
thanks

Comment by Tom Mueller [ 20/Dec/10 ]

The usage message is either automatically generated based on the @Param annotations, or, if the @I18n annotation is provided, and the appropriate key exists in the LocalStrings.properties file, then the usage message is taken from the properties file.

In the case of create-file-user, it is the latter. The usage message is in the LocalStrings.properties file, and that message is missing the --target part.

Reassigning back to Kumar to fix.

Comment by Tom Mueller [ 21/Dec/10 ]

The 2.1.1 release has a --target option for the create-file-user command, so this is a regression.





[GLASSFISH-3121] race condition in NssStore.java Created: 04/Jun/07  Updated: 13/Jun/07

Status: Reopened
Project: glassfish
Component/s: security
Affects Version/s: 9.1pe
Fix Version/s: 9.1pe

Type: Bug Priority: Minor
Reporter: kumarjayanti Assignee: kumarjayanti
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 3,121

 Description   

> Could you please forward this bug reported from Sanjeev Krishnan's
> code analysis tool.
>
> thanks, Larry White

>
> NssStore
> Race Condition
> read/write to _password not adequately synchronized
>
> 093 public static String getNssDbPassword()
> 094 {
> 095 if (_password == null)

{ > 096 _password = System.getProperty(SystemPropertyConstants.NSS_DB_PASSWORD_PROPERTY); > Race Condition : Write / read to static field NssStore._password is NOT adequately synchronized. > 097 }

> 098 return _password;
> 099 }



 Comments   
Comment by kumarjayanti [ 04/Jun/07 ]

The fix for the reported race condition is ready. However there needs to be an
investigation on why a SYSTEM property is being used at all :

System.getProperty(SystemPropertyConstants.NSS_DB_PASSWORD_PROPERTY);

Comment by gfbugbridge [ 04/Jun/07 ]

<BT6565526>

Comment by kumarjayanti [ 06/Jun/07 ]

Fixed the race condition.
May file another issue after discussion with RON on whether or not the System
Property should have been used.

Comment by dpatil [ 06/Jun/07 ]

Broke enterprise profile after this change, so reverted the checkin.

Comment by rameshm [ 13/Jun/07 ]

As per agreement in bugscum meeting, changing the priority to P4. Bugswat team felt
that, this is not a must fix for AS 9.1 and may be risky to attempt to fix at
this time in AS 9.1.





Generated at Sat May 30 17:58:19 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.