How is your <security-constraint> section set?

e.g.
        <security-constraint>
                <web-resource-collection>
                        <web-resource-name>EJB</web-resource-name>
                        <url-pattern>/ejbtest.jsp</url-pattern>
                        <url-pattern>/ejbtest2.jsp</url-pattern>
                </web-resource-collection>
                <auth-constraint>
                        <role-name>web-app-users</role-name>
                </auth-constraint>
        </security-constraint>
        <login-config>
                <auth-method>BASIC</auth-method>
        </login-config>
        <security-role>
                <role-name>web-app-users</role-name>
        </security-role>

Dave Smith
Senior Team Leader
Aristocrat Technologies Australia Pty Ltd

mailto:[EMAIL PROTECTED]


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, 28 July 2000 9:32
To: Orion-Interest
Subject: Authentication is not to spec




Authentication does not seem to be working in the Servlets and the EJBs.
Here
is the situation:

web.xml:
<web-app>
     ....
     <servlet>
          <servlet-name>TSIS</servlet-name>
          <display-name>TSIS</display-name>
          <servlet-class>com.tsis.servlets.TSISServlet</servlet-class>
     </servlet>
     <servlet-mapping>
          <servlet-name>TSIS</servlet-name>
          <url-pattern>/TSIS/*</url-pattern>
     </servlet-mapping>
     <servlet>
          <servlet-name>Login</servlet-name>
          <display-name>Login</display-name>
          <servlet-class>com.tsis.servlets.auth.Login</servlet-class>
     </servlet>
     <servlet-mapping>
          <servlet-name>Login</servlet-name>
          <url-pattern>/Login</url-pattern>
     </servlet-mapping>

     <login-config>
          <auth-method>Basic<auth-method>
          <realm-name>Brica<realm-name>
          <form-login-config>

<form-login-page>com.tsis.servlets.auth.FormLogin</form-login-page>
               <form-error-page></form-error-page>
          </form-login-config>
     </login-config>
</web-app>


Now, com.tsis.servlets.auth.Login is a servlet that implements Basic
Authentication.  This part of basic Authentication works fine, BUT  the
problem
is that Orion does not stuff the username into the
request.getUserPrincipal(),
which then, in turn, causes the EJB's EntityContext.getCallerPrincipal() to
return "guest" instead of returning who is actually calling the bean.  I
list
the spec below that explains what should happen.  Please, pay attention to
the
bold parts:


3.5.2 Caller Authorization

A J2EE product must enforce the access control rules specified at deployment
time (see Section 3.6, ?Deployment Requirements?) and more fully described
in
the EJB and Servlet specifications. It must be possible to configure a J2EE
product so that the propagated caller identity is used in authorization
decisions. This is, for all calls to all enterprise beans from a single
application within a single J2EE product, the principal name returned by the
EJBContext method getCallerPrincipal must be the same as that returned by
the
first enterprise bean in the call chain. If the first enterprise bean in the
call chain is called by a servlet or JSP page, the principal name must be
the
same as that returned by the HttpServletRequest method getUserPrincipal in
the
calling servlet or JSP page. (However, if the HttpServletRequest method
getUserPrincipal returns null, the principal used in calls to enterprise
beans
is not specified by this specification, although it must still be possible
to
configure enterprise beans to be callable by such components.) Note that
this
does not require delegation of credentials, only identification of the
caller.
This principal must be the principal used in authorization decisions for
access
to all enterprise beans in the call chain. The requirements in this
paragraph
apply only when a J2EE product has been configured to propagate caller
identity.
J2EE products may also provide other deployment modes or configuration
options
in which the original caller identity is not propagated to all components in
the
call chain. For instance, some enterprise beans may execute with their own
identity and corresponding privileges, and that identity may be made
available
to other enterprise beans that they call.



If Orion does not implement this, then how do I get the same effect in Orion
because I can not find any documentation on it?

Thanks!



Reply via email to