I tired this and the correct type of Authentication showed up, but it does not
work. When the form, or Basic Auth, pops up, I enter in he username and
password, and I keep getting an Authentication Failed with Basic Auth, and the
form just keeps popping up.
<web-app>
<display-name>TSIS Servlet</display-name>
<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.FormLogin</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>Login</servlet-name>
<url-pattern>/Login</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Everything</web-resource-name>
<url-pattern>/TSIS/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>guest</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>Form</auth-method>
<realm-name>Brica</realm-name>
<form-login-config>
<form-login-page>Login</form-login-page>
<form-error-page></form-error-page>
</form-login-config>
</login-config>
<security-role>
<role-name>guest</role-name>
</security-role>
</web-app>
Dave Smith <[EMAIL PROTECTED]> on 07/27/2000 07:07:29 PM
To: PETER V MINEARO/TheSphereHQ@TheSphereHQ
cc:
Subject: RE: Authentication is not to spec
I suspect you have to let the server trigger the authentication, rather than
rely on it noticing that it has been to the Login servlet and noticing that
that is also a login page.
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 11:56
To: Dave Smith
Subject: RE: Authentication is not to spec
Thanks for the info!! I am definately going to try what you said; I hope it
works. But I will have to wait for morning.
-- BUT --
I figure if I do the following change, then the servlet should know what the
security page is.
<servlet>
<servlet-name>Login</servlet-name>
<display-name>Login</display-name>
<servlet-class>com.tsis.servlets.auth.FormLogin</servlet-class>
</servlet>
<servlet-m
<login-config>
<auth-method>Form<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>
Dave Smith <[EMAIL PROTECTED]> on 07/27/2000 06:42:24 PM
To: PETER V MINEARO/TheSphereHQ@TheSphereHQ
cc:
Subject: RE: Authentication is not to spec
How does the server know that your Login Form is actually part of the
security for your pages when you have not tied them together.
All you need is to add
<security-constraint>
<web-resource-collection>
<web-resource-name>Everything</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>web-app-users</role-name>
</auth-constraint>
</security-constraint>
It has to be worth a try.......
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 11:36
To: Dave Smith
Subject: RE: Authentication is not to spec
We are not using the <security-constaint> section. We are storing all of
our
users and their permissions in a database; rather than, putting then in the
XML
file. The spec doesn't seem to indicate that you need to have this in the
web.xml. In fact, I have tried to implement this part of the spec, but no
go:
SRV.11.5.2.1 Login Form Names
Form based login and URL based session tracking can be problematic to
implement.
It is strongly recommended that form based login only be used when the
session
is being maintained by cookies or by SSL session information. In order for
the
authentication to proceed appropriately, the action of the login form must
always be j_security_check. This restriction is made so that the login form
will always work no matter what the resource is that requests it and avoids
requiring that the server to process the outbound form to correct the action
field. Here is an HTML sample showing how the form should be coded into the
HTML page:
<form method=POST action=j_security_check>
<input type=text name=j_username>
<input type=password name=j_password>
</form>
In Orion, do I need the <security-constraint> section?
Dave Smith <[EMAIL PROTECTED]> on 07/27/2000 06:10:17 PM
To: PETER V MINEARO/TheSphereHQ@TheSphereHQ
cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: RE: Authentication is not to spec
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!
