Applications fails to authenticate/authorize when logging into repository after security constraints are added to web.xml

[mashama]

I am running MS 3.3 on EAP 6.1.Final.  After adding the following security constraints to the application I am developing the application fails to authenticate/authorize when logging into the MS repository I created.  The application works fine w/o the security constraints.  I attempted to follow the instructions on "authentication and authorization" within the documentation but my efforts to add modeshape users and roles and then authenticate/authorize with those credentials got me nowhere.  It should be duly noted that the documentation has a TODO note that says it needs to be updated.

Why does the addition of these security constraints to the web application force me to authenticate/authorize with the MS repository?  How do I correctly authenticate/authorize with the repository after these security constraints are added?

Stacktrace:

10:06:11,520 ERROR [com.chp.valuequest.controller.Worker] (EJB default - 10) javax.jcr.LoginException: Unable to create session for workspace 2213 in repository salesapp: authentication or authorization failed. Check credentials.: javax.jcr.LoginException: Unable to create session for workspace 2213 in repository salesapp: authentication or authorization failed. Check credentials.
          at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:659) [modeshape-jcr-3.3.0.Final.jar:3.3.0.Final]
          at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:574) [modeshape-jcr-3.3.0.Final.jar:3.3.0.Final]
          at org.modeshape.jcr.JcrRepository.login(JcrRepository.java:153) [modeshape-jcr-3.3.0.Final.jar:3.3.0.Final]
          at com.chp.valuequest.util.Modeshape.login(Modeshape.java:25) [classes:]

web.xml snippet:

	<security-constraint>
		<web-resource-collection>
			<web-resource-name>HtmlAuth</web-resource-name>
			<description>application security constraints</description>
			<url-pattern>/*</url-pattern>
			<http-method>GET</http-method>
			<http-method>POST</http-method>
		</web-resource-collection>
		<auth-constraint>
			<role-name>RestAdmin</role-name>
		</auth-constraint>
	</security-constraint>
	<security-constraint>
		<web-resource-collection>
			<web-resource-name>HtmlAuth</web-resource-name>
			<description>application security constraints</description>
			<url-pattern>/rest/*</url-pattern>
			<http-method>GET</http-method>
			<http-method>POST</http-method>
		</web-resource-collection>
		<auth-constraint>
			<role-name>RestUser</role-name>
		</auth-constraint>
	</security-constraint>

[hchiorean]

It seems your configuration is overriding the default security domain from the EAP kit (modeshape-security) with an empty one, which doesn't provide an authentication section.

I don't think this is a valid usage of a security domain.

[mashama]

Just to be clear for those whom may read this thread I incorrectly configured the modeshape-security security domain in my standalone.xml configuration file.  I had to remove the configuration file as an attachment on this thread because I didn't sanatize it.  

Thanks for your help Horia.  What is confusing is that the application was able to authenticate with MS without providing credentials until I added the security constraints to the application.  Please tell me if my understanding is correctly.  Prior to adding the security contraints to my application it was authenticating with MS as an anonomous user.  After adding the security constraints the application required authentication and thus the application was no longer authenticating with MS as an anonomous user?!?!

[rhauch]

Thanks for your help Horia.  What is confusing is that the application was able to authenticate with MS without providing credentials until I added the security constraints to the application.  Please tell me if my understanding is correctly.  Prior to adding the security contraints to my application it was authenticating with MS as an anonomous user.  After adding the security constraints the application required authentication and thus the application was no longer authenticating with MS as an anonomous user?!?!

By default, ModeShape allows anonymous sessions -- basically that applications can create a session without specifying any credentials. This is to make sure it is easy to get an application working for the first time.

However, whether ModeShape allows anonymous sessions (and if so, which privileges they are granted) is configured in the ModeShape configuration. For example, the default behavior is essentially similar to configuring this part of the JSON configuration file:

{

    ...

    "anonymous" : {

      "roles" : ["readonly","readwrite","admin"],

      "username" : "<anonymous>",

      "useOnFailedLogin" : false

  },

  ...

}

The equivalent in the AS7/EAP configuration XML file is:

<repository name="sample"

            anonymous-roles="readonly readwrite admin"

            anonymous-username="&lt;anonymous&gt;"

            use-anonymous-upon-failed-authentication="false" >

    ...

</repository>

Remember, these are the defaults, so not providing them is just like using these default values. You can set the roles to an empty array in JSON or an empty string in the AS7/EAP XML to completely turn off anonymous authentication, or use whatever subset of roles you want. With the "useOnFailedLogin" field in JSON or the "use-anonymous-upon-failed-authentication" attribute in the XML to "false", any failed authentication attempts will result in an exception. However, you could set this to true if you want such failed attempts to instead result in an anonymous session. (This would be better if anonymous only allowed read-only access; thus any failed authentication would result not in a failured but in a read-only anonymous session. It's up to you if you want to enable this behavior.)

Now, when your application does provide credentials, then ModeShape will expect that those credentials can indeed be authenticated. When you didn't use the default security domain that ModeShape normally uses, none of the credentials will authenticate.

I hope this helps.

[mashama]

Let me attempt to be as clear as possible about the behavior I seemed to experience.  The application was working without fail as I was not explicitly providing credentials when creating the session.  After I added the BASIC authentication to the application via the web.xml file, MS started returning javax.jcr.LoginException even though the application was still NOT providing credentials.  This is what I am trying to understand especially when you say that "ModeShape allows anonymous sessions -- basically that applications can create a session without specifying any credentials".  So I guess my question is whether or not the application was implicitly providing credentials, per the requisite BASIC authentication used to access the application, when connecting to ModeShape?  If so then the javax.jcr.LoginException would be consistent with me not using the default securit domain and MS not being able to authenticate any credentials because of this.

This is not a big deal to me right as my application is working now.  I am just curious as to whether or not I can secure my application running on EAP 6.1 with BASIC authentication and at the same time authenticate anonomously with MS (running on the same EAP instance)?  If the answer is no to that then my understanding would be that ... like an SSO capability MS is using the same credentials as the ones provided via the BASIC authentication requied for the application. Please note that I am using resource injection to inject the repository in my code.

Sorry for any lack of clarity.

Randall Hauch wrote:

Thanks for your help Horia.  What is confusing is that the application was able to authenticate with MS without providing credentials until I added the security constraints to the application.  Please tell me if my understanding is correctly.  Prior to adding the security contraints to my application it was authenticating with MS as an anonomous user.  After adding the security constraints the application required authentication and thus the application was no longer authenticating with MS as an anonomous user?!?!

By default, ModeShape allows anonymous sessions -- basically that applications can create a session without specifying any credentials. This is to make sure it is easy to get an application working for the first time.

However, whether ModeShape allows anonymous sessions (and if so, which privileges they are granted) is configured in the ModeShape configuration. For example, the default behavior is essentially similar to configuring this part of the JSON configuration file:

{

    ...

    "anonymous" : {

      "roles" : ["readonly","readwrite","admin"],

      "username" : "<anonymous>",

      "useOnFailedLogin" : false

  },

  ...

}

The equivalent in the AS7/EAP configuration XML file is:

<repository name="sample"

            anonymous-roles="readonly readwrite admin"

            anonymous-username="&lt;anonymous&gt;"

            use-anonymous-upon-failed-authentication="false" >

    ...

</repository>

Remember, these are the defaults, so not providing them is just like using these default values. You can set the roles to an empty array in JSON or an empty string in the AS7/EAP XML to completely turn off anonymous authentication, or use whatever subset of roles you want. With the "useOnFailedLogin" field in JSON or the "use-anonymous-upon-failed-authentication" attribute in the XML to "false", any failed authentication attempts will result in an exception. However, you could set this to true if you want such failed attempts to instead result in an anonymous session. (This would be better if anonymous only allowed read-only access; thus any failed authentication would result not in a failured but in a read-only anonymous session. It's up to you if you want to enable this behavior.)

Now, when your application does provide credentials, then ModeShape will expect that those credentials can indeed be authenticated. When you didn't use the default security domain that ModeShape normally uses, none of the credentials will authenticate.

I hope this helps.

[rhauch]

Okay, most of my explanation correctly described the defaults in a JavaSE environment, but I completely neglected to address how ModeShape inside EAP is configured by default. My apologies.

I am just curious as to whether or not I can secure my application running on EAP 6.1 with BASIC authentication and at the same time authenticate anonomously with MS (running on the same EAP instance)?  If the answer is no to that then my understanding would be that ... like an SSO capability MS is using the same credentials as the ones provided via the BASIC authentication requied for the application. Please note that I am using resource injection to inject the repository in my code.

When you install the ModeShape subsystem, it automatically integrates with EAP's JAAS and Servlet mechanisms, so there are several ways of obtaining a session:

• for anonymous session, pass a javax.jcr.GuestCredentials or an AnonymousCredentials (which allows custom session attributes) into the "login" method
• for an authenticated session, either pass nothing in (presuming you've set up the security domain and your application) or explicitly get the JAAS LoginContext and create a JaasCredentials. The first will definitely use the same subject that your application is authenticating, while the second will do that iff you get the LoginContext for the authenticated subject (though you can also get a LoginContext for a different authenticated subject than what your application is using; kind of arcane.)
• for an authenticated session bound to the servlet's context, you would construct a ServletCredentials instance (passing in the HttpServletRequest) and use that into the "login" method. Honestly, in EAP there's probably not much benefit to using servlet authentication since JAAS can do everything servlet authentication can do (and more).

So, let me try to explain what you were seeing. IIUC, you were passing no credentials into the "login" method, so when you're application didn't use security the no-credentials option corresponded only to an anonymous session. However, as soon as you set up your application's security, ModeShape tried to authenticate with JAAS using the subject associated with the current thread. And because JAAS couldn't authenticate (because the security domain was not set up correctly), ModeShape threw an exception upon "login". As soon as you corrected your security, then JAAS worked and ModeShape returned an authenticated session.

BTW, resource injection shouldn't affect JAAS integration, since the beauty of JAAS is that it should associated the authenticated subject with the current thread of your application.

Hopefully this helps. If not, please let me know what question I'm not answering.