What exactly is missing or not being set? Examples and concrete data please. What does 'session.getUserID()' return?

Also, please confirm that the ModeShape repository configuration's "useAnonymousAccessOnFailedLogin" repository option is not being set to 'true' (the default is 'false') or is explicitly set to 'false'.

Finally, if the user is indeed authenticating, due to the above discussion, this may mean that users are not successfully authenticating with JAAS, and if the correct username/password are being used then the JAAS/ModeShape configuration may not be correct.

Link: Added: This issue is related to MODE-1222

Link: Removed: This issue is related to MODE-1222 

Not sure if this helps, but 'session.getUserID()' returns string '<anonymous>' (without the quotes).

That definitely means the user is being logged in as anonymous. So if the BRMS code is explicitly doing this (by creating sessions without credentials), then this is either a bug in BRMS and needs to be changed, or it is working as coded. :-)

If BRMS is creating sessions with credentials, then ModeShape is not able to authenticate the credentials using JAAS. Either the credentials are wrong (e.g., the JAAS files do not contain the right information), or JAAS is improperly configured and ModeShape is not able to use JAAS to authenticate any credentials. Either way, this is a BRMS issue and not a ModeShape issue.

I'm assigning to Kurt, as this is Guvnor/BRMS issue and not a ModeShape issue. I hope that's right.

Might be related to bug 724683.

I've listed this as not needing a release note (the issue appears to be between internal development versions).

Let me know if I got it wrong. Change the technical_note flag to '?' to indicated a release note is required.

Thanks
- Lee

The problem is in org.drools.guvnor.server.repository.RepositoryStartupService#create():
it always logs in with a static admin user.

For guvnor 5.4, which will clean up the repository boot mess and use weld-seam3, we can fix this decently. 5.2 is a different story...

I would not think this a blocking bug.  It would be good to get it cleaned for 5.2, but given where it is not critical for the release

My previous comment is wrong: that's just the setup session. RulesRepositoryManager does seem to log it in with the current username, but there's a fallback mechanism.

Either way, I 'll take this requirement along for the 5.4 boot cleanup.

Lee, since we're not fixing this for 5.2, would you make sure that it is mentioned in the relase notes?

Thanks Lukáš,

Will do.

Lukas, Lee: In 5.2, has anyone tried with the jaasConfigName set correctly in the components.xml as specified in the manual?

"To use JAAS and the modeshape policy comment out the defaultAuthenticator section and uncomment
    the jaas-configuration section, and change the policy name from 'other' to 'modeshape'"

Not sure if it's related, but it could be.

I've just tried that and it didn't help.

The Guvnor login uses the Seam logon code:

Relevant code:

Identity.instance().getCredentials().setUsername( userName );
Identity.instance().getCredentials().setPassword( password );

try {
   Identity.instance().authenticate();
} catch ( LoginException e ) {
    log.error( "Unable to login.", e );
    return false;
} 

And Seam sets the Subject in Seam context, this works fine:

Subject subject = Identity.instance().getSubject(); 

However ModeShape (in https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main/java/org/modeshape/jcr/security/JaasProvider.java) does this

Subject subject = Subject.getSubject(AccessController.getContext());

And this is *not* set. 

Anil says: "Subject.getSubject()  is a JDK construct that does not hold well inside Java EE.  The need will be to support call paths with Subject.doAS calls  to actually get the subject. I am unsure if all app servers support this construct. If Modeshape is EE container agnostic, then maybe they need some app server bridges or such to get the subject."

Also note that according to Shane Seam 3 is using PicketLink: "This isn't supported in Seam either - the Subject is simply used as a holder for session-scoped user state.  In Seam 3 it's actually been removed, in favour of the User API classes in PicketLink.  Is that the only way that the Subject may be set in Modeshape?  (I've actually been using Modeshape for a Seam-based project, but haven't had to write any security-related code as yet)." 

With this info it looks like ModeShape will need to add ways to grab the Subject so that it can obtain the username from it (to set in the JCRSession).
 
Hopefully Randall will comment on this matter.

--Kurt

The fact that the standard Java API to access the Subject from the JAAS LoginContext does *not* work within J2EE and the app server is very troubling, but apparently this is a problem that is well-known in J2EE circles (of which I am clearly not a member).

According to Kurt, the Guvnor code obtains the Subject from the Seam context. If this is true (and acceptable), perhaps the easiest way to fix this is to enhance ModeShape to define an additional JCR Credentials class that allows this Subject to be passed into ModeShape. This new Credentials class should then be used in J2EE applications that use ModeShape with JAAS security.

I still have not heard back from Anil or Shane as to the "proper" way to grab the Subject. If there's no other way than the Seam context, we may have to add the new Credentials implementation.

I don't see a way to add a link to a JIRA issue, but I've created https://issues.jboss.org/browse/MODE-1270 to track this issue in ModeShape. It is currently prioritized as a blocker.

I don't see a way to add a link to a JIRA issue, but I've created https://issues.jboss.org/browse/MODE-1270 to track this issue in ModeShape. It is currently prioritized as a blocker.

Anil got back to me with the suggestion:

1) Add a 'provided' dependency on:

<dependency>
<groupId>org.jboss.spec.javax.security.jacc</groupId>
<artifactId>jboss-jacc-api_1.4_spec</artifactId>
<version>1.0.0.Final</version>
<scope>provided</scope>
</dependency>

2) Change the ModeShape JAAS authorization provider implementation to look for the Subject as it currently does, but if it is null (as is the case when deployed into a J2EE container like JBoss AS/EAP) then try to use the JACC API (if it is available; thus the 'provided' dependency scope) to access the Subject. According to Anil, the following "is a JACC mandated construct.  JACC is part of all EE4+ app servers.  We support this in JBAS. Guessing other app servers do too.  Most of AS customers use this construct."

import javax.security.auth.Subject;
import javax.security.jacc.PolicyContext;
import javax.security.jacc.PolicyContextException;

/** The JACC PolicyContext key for the current Subject */
private static final String SUBJECT_CONTEXT_KEY = "javax.security.auth.Subject.container";
Subject caller = (Subject) PolicyContext.getContext(SUBJECT_CONTEXT_KEY);

Added the fix to the master:
https://github.com/droolsjbpm/guvnor/commit/629534cc70d8600e47228ca1144a69cc2cea6823#commitcomment-614859

This also required an update from ModeShape, so that it reads the JBoss Security context. Randall, maybe you add the link to your commit?

Created attachment 525187 [details]
patch to set the security context

patch has been committed to the guvnor master branch

The ModeShape change was already committed to the '2.5.x' branch, which is being used by SOA-P and BRMS, and to the 'master' branch. For details, see MODE-1270. These are the changes that were made to find the JAAS Subject using the JACC API when running within a J2EE container: https://github.com/ModeShape/modeshape/pull/198

BTW, the above reference pull-request was committed on the '2.5.x' branch with this commit: https://github.com/ModeShape/modeshape/commit/64bbca4b72024b3f9009eae7bb4f75d0808317cb

VERIFIED on JBoss containers. It will not work with neither EWS and WAS.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When using JAAS authentication and no credentials were supplied, ModeShape's Repository.login(...) methods resulted in a session that did not contain the proper user ID. This issue was resolved by adjusted the JAAS authentication  provider to work within J2EE containers.

Ignore comment 25, some configuration steps were missed when verifying the fix manually and Guvnor was still running with Jackrabbit repository. Therefore, it appeared as the bug had gone.

Automated tests revealed the bug is still present. Reopening this one. The technical note should be updated.

Jiri, I was asked to commit the fix to the guvnor trunk only. So unless you are building with the trunk it will still be broken.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When using JAAS authentication and no credentials were supplied, ModeShape's Repository.login(...) methods resulted in a session that did not contain the proper user ID. This issue was resolved by adjusted the JAAS authentication  provider to work within J2EE containers.+When using JAAS authentication and no credentials are supplied, ModeShape's Repository.login(...) methods result in a session that does not contain the proper user ID. <!-- This issue was resolved by adjusted the JAAS authentication  provider to work within J2EE containers. -->

This issue still occurs in BRMS 5.3.0 ERx releases. Maybe the fix has not made it to the current Guvnor branch?

*** Bug 724683 has been marked as a duplicate of this bug. ***

Randall Hauch <rhauch> updated the status of jira MODE-1270 to Closed

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.