JSF Authentication

[Former Member]

Hello,

I'm trying to protect a JSP behind a login page on SAP NW 7.4. Nobody should be able to access the page unless they login beforehand (using the default NW Login).

Like stated here: Specifying Authentication for Java Applications - Integrating Security Functions - SAP Library. (and the pages in the same chapter)

I added these lines to the web.xml in the Web project:

<login-config>

  <auth-method>FORM</auth-method>

</login-config>

And these in web-j2ee-engine.xml:

<login-module-configuration>

  <login-module-stack>

  <login-module>

  <login-module-name>BasicPasswordLoginModule</login-module-name>

  <flag>SUFFICIENT</flag>

  </login-module>

  </login-module-stack>

</login-module-configuration>

However, when I deploy the project I can still access the page without providing my credentials first.

Can you help me find whats missing?

Thanks and best Regards

Fabio Zuber

[Former Member · Accepted solution]

Hi Fabio,

In addition to setting the login configuration and the login module, you would also need to specify which resources of your application are protected. An authentication will be triggered only for protected resources of your application. Public resources you can access without any authentication.

Specifying which resources are protected is done in the web.xml. For more information, please see Creating a Security Constraint - Integrating Security Functions - SAP Library

Best regards,

Nikolay

[Former Member · Accepted solution]

Hey Nikolay

Thanks for the tip. I added this in the web.xml:

<security-constraint>

  <web-resource-collection>

  <web-resource-name>CommunicationChannelUtilWeb</web-resource-name>

  <url-pattern>*</url-pattern>

  <http-method>GET</http-method>

  <http-method>POST</http-method>

  </web-resource-collection>

  <!-- Specify the role that all users must have to access the application -->

  <auth-constraint>

  <role-name>CommunicationChannelUtilRole</role-name>

  </auth-constraint>

  <user-data-constraint>

  <transport-guarantee>NONE</transport-guarantee>

  </user-data-constraint>

</security-constraint>

and this in the web-j2ee-engine.xml:

<security-role-map>

  <role-name>CommunicationChannelUtilRole</role-name>

  <server-role-name>Everyone</server-role-name>

</security-role-map>

I think the page now tries to route me to the login page first.

However If I access the page I get a 500 Internal Server Error. The log shows these Exceptions:

500 Internal Server Error is returned for HTTP request [https://system:port/CommunicationChannelUtilWeb/faces/login.xhtml]: 
  component [Faces Servlet], 
  web module [CommunicationChannelUtilWeb], 
  application [sap.com/CommunicationChannelUtilEAR], 
  DC name [sap.com/CommunicationChannelUtilEAR], 
  CSN component[], 
  problem categorization [com.sap.ASJ.web.000137], 
  internal categorization [1833011496]. 

[EXCEPTION]
com.sap.engine.services.servlets_jsp.server.exceptions.WebServletException: Error occurred in dispatching request to servlet [/faces/login.xhtml].
at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doCached(RequestDispatcherImpl.java:683)
at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:497)
at com.sap.engine.interfaces.security.auth.WebCallbackHandler.forward(WebCallbackHandler.java:304)
...


Caused by: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.render.RenderKitFactory
at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:725)
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:239)
at com.sun.faces.context.FacesContextImpl.<init>(FacesContextImpl.java:130)
at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:108)
at com.sap.tc.ls.faces.context.UCFFacesContextFactory.getFacesContext(UCFFacesContextFactory.java:58)
at com.sap.tc.ls.faces.context.UCFFacesContextFactory.getFacesContext(UCFFacesContextFactory.java:28)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:261)
at com.sap.engine.services.servlets_jsp.server.Invokable.invoke(Invokable.java:152)
at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doCached(RequestDispatcherImpl.java:664)
... 48 more

I checked these thread without finding a solution to my problem.

• http://stackoverflow.com/questions/5259145/exception-could-not-find-factory-javax-faces-context-face...

Thanks for the help.

Best regards

Fabio

[Former Member · Accepted solution]

Hi Fabio,

Indeed you are being redirected tot he login page . This is some progress.

You are receive the above exception, because it tries to find a login page, but such is not available with your application. And this is because you have configured your application to use FORM:

<login-config>

  <auth-method>FORM</auth-method>

</login-config>

You have two options.The first one is to create a login page. The last section in this page Specifying Authentication for Java Applications - Using Central Development Services - SAP Library describes how to do that.

The second options is to use the default logon page provided by the SAP NetWeaver AS Java Server. To do that you just have to change the login configuration to BASIC

<login-config>

  <auth-method>BASIC</auth-method>

</login-config>

Best regards,

Nikolay

[Former Member · Accepted solution]

Hey Nikolay

Thank you very much for your help. I want to use the default SAP login Page, so I didn't specify a login page.

From Specifying Authentication for Java Applications - Using Central Development Services - SAP Library:

If you do not specify your own login and error pages, the AS Java uses the corresponding pages of its own default logon application. We recommended that you use the default pages to ensure a consistent user experience across all applications and because those pages contain built-in security features.

The BASIC authorization method doesn't operate via form (i.e login page). It opens a "login popup" in your Browser whenever one tries to open a page. Unfortunately HTTP BASIC has some security flaws and should not be used anymore.

I suspect that something on the run time environment is flawed. Any ideas?

Best regards

Fabio

[Former Member · Accepted solution]

Hi Fabio,

You are absolutely right. I do not know what I was thinking when I wrote my reply.

Indeed when you are using the FORM authentication the default logon page should be shown if no page is configured.

Do you think that it is possible to send paste the whole web.xml and web-j2ee-engine.xml?

Are you using JSF in your application?

Best regards,

Nikolay

[Former Member · Accepted solution]

Hey Nikolay

Yes I'm using JSF as a frontend to an ejb project.

Sure I can share my current web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
       http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">

  <display-name>CommunicationChannelUtilWeb</display-name>

  <welcome-file-list>
  <welcome-file>faces/index.jsp</welcome-file>
  </welcome-file-list>

  <servlet>
  <servlet-name>Faces Servlet</servlet-name>
  <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
  <servlet-name>Faces Servlet</servlet-name>
  <url-pattern>/faces/*</url-pattern>
  </servlet-mapping>

  <security-constraint>
  <web-resource-collection>
  <web-resource-name>CommunicationChannelUtilWeb</web-resource-name>
  <url-pattern>*</url-pattern>
  <http-method>GET</http-method>
  <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint>
  <role-name>CommunicationChannelUtilRole</role-name>
  </auth-constraint>
  <user-data-constraint>
  <transport-guarantee>NONE</transport-guarantee>
  </user-data-constraint>
  </security-constraint>

  <login-config>
  <auth-method>FORM</auth-method>
  </login-config>

  <ejb-local-ref>
  <ejb-ref-name>CommunicationChannelUtil</ejb-ref-name>
  <ejb-ref-type>Session</ejb-ref-type>
  <local>com.siemens.edi.CommunicationChannelUtilBeanLocal</local>
  </ejb-local-ref>

</web-app>

And the web-j2ee-engine.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-j2ee-engine xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="web-j2ee-engine.xsd">
  <spec-version>2.4</spec-version>

  <security-role-map>
  <role-name>CommunicationChannelUtilRole</role-name>
  <server-role-name>Everyone</server-role-name>
  </security-role-map>

  <login-module-configuration>
  <login-module-stack>
  <login-module>
  <!-- Contains information about one login module -->
  <login-module-name>BasicPasswordLoginModule</login-module-name>
  <flag>SUFFICIENT</flag>
  </login-module>
  </login-module-stack>
  </login-module-configuration>

</web-j2ee-engine>

Thanks and best regards

Fabio

[Former Member · Accepted solution]

Hi Fabio,

I have an assumption of what might be happening.

At some point in time the web.xml have contained a login and error page configuration similar to:

<form-login-config>

    <form-login-page>/faces/login.xhtml</form-login-page>

    <form-error-page>/faces/error.xhtml</form-error-page>

</form-login-config>

You have removed the configuration and have redeployed the application, but the configurations have remained stored in the database. That is why the application tries to redirect you to /faces/login.xhtml and not to the default login page.

The easiest way to correct this behavior is to remove the application and to deploy it again, not just update it.

Regarding the web.xml I have two remarks.

You have to add a security role declaration for every security role:

<security-role>

  <description>Communication Channel Util Role</description>

  <role-name>CommunicationChannelUtilRole</role-name>

</security-role>

You should also remove the http-methods from the security constraint, otherwise your application will be susceptible to verb tampering attack as all other http methods will not be protected. Of course you could leave them like that if you would want for the other http methods to not require an authentication, but this is generally not the case.

Best regards,

Nikolay

[Former Member · Accepted solution]

Hey Nikolay

Your assumption was correct. The system cached the old references to some login pages. After undeploying and redeploying the application everything works fine .

Thank you very much for your help.

PS: I also corrected your remarks.

Best regards

Fabio