Laird Nelson wrote:
> francis pouatcha wrote:
> > Programaticaly creating users and principal (in the bean code) is a bad
> > practice.
>
> [snip]
>
> > > Do principals represent new dynamic users that are created as
> > > part of business processes, or do they represent system/operations-level
> > > users?
> >
> > I'd choose the first (business process users).
>
> So given that you think that principals *do* represent new dynamic
> users, why can't I create them programmatically? If they're new and
> dynamic, then how can I possibly NOT create them programmatically?
Sorry, I where talking about writing portable applications. You have two ways for
writing EJB clients.
-> Either you write them to be portable clients that could be distributed with
the J2EE Application, e.g web clients .war (servlets, jsp) and application clients
.jar (what I call clientlets). These clients do have no knowledge of the J2EE
server's uthentication technology (e.g. the java.util.Principal implementation to
use for creating principals). Each of these clients run into containers that take
care of "dynamically" creating principals and authenticating components (clients)
they are hosting to the EJB Server. The implementation of containers (or client
runners) is providet by the j2ee server.
->You also have the possibility to write standalone clients and servlets "whose
runner are not related with the EJBServer". You may dinamically create principal to
authenticate these clients to the EJBserver. For doing this, you need some
knowledge of the authentication technology of the EJBServer. If the EJBServer using
IIOP for example, you need some way of telling to the ORB who you are before
invoking the call to the EJBServer.
>
>
> > I'd couple EJB and Servlet authentication and leave authenticatication issues
> > to my EJB- and my WEBserver (whenever possible). Coding authentication into
> > your servlet kills the portability of your web components.
>
> I've now heard this from lots of people. I still don't know what it
> means.
-> Let say your EJBServer (container for Enterprise Beans) and your servlet enabled
WebServer (container for Servlets and JSP's) are all accessing the same
authentication database (the simpliest authentication database is the realm named
"default" provided by the J2EE-RI).
-> and get a look at the following scenario:
<container-implementation>
<web-server>
The Webserver uses the authentication mode "basic" (http basic authentication)
to get the name=duke and password=java of the user hitting from a Webbrowser. The
Webserver then looks into the default realm to ensure there is a user "duke" with
password "java" and register the servlet's thread to some kind of SecurityService
with these security attributes.
</web-server>
</container-implementation>
<your-implementation>
<servlet>
The servlet get the InitialContext of the EJBServer and get a refrerence to
AccountHome. It then try following calls
String key = HTTPServletRequest.getParameter("acc_id");// ="120345"
Account acc = PortableRe... (AccountHome.findByPrim...(key));
acc.suspend();
</servlet>
</your-implementation>
<container-implementation>
<web-server>
When the Account.suspend() request comes to the client ORB (suppose we are using
IIOP), the ORB get the installed SecurityService and ask for security attributes
associated with the calling thread. The SecurityService retrieves and returns
"duke" without any other details (like groups, ...). The client ORB associate this
attribute with the call and sends the IIOP packet to the server ORB.
</web-server>
<ejb-server>
The server ORB unpacks the request, get the associated security attribute "duke"
and associate it with the thread serving that request. Before forwarding the
request to the bean, the EJBServer checks wether the create method is asssociated
with a security role (let say "account_admin" defined by the bean provider). It
then looks in some kind of mapping table to see our real live's groups associated
with the role "account_admin" and it gets "bank_teller" ("bank_teller" is a real
group used in our bank to designate all employees that are allowed to manage
clients accounts). The EJBServer then looks up the co-used authentication database
to see if "duke" has been assigned the role "bank_teller", if it's the case, it
forwards the call to the AccountEJB, if not, it throws an Exception to the servlet
saying that "duke" is not authorised to call AccountEJB.suspend().
</ejb-server>
</container-implementation>
Integrating Servlet and EJB authentication means configuring them to use the same
authentication database (like the "default" realm in the J2EE-RI). Doing so, you
save the step for authenticating your Webserver to the EJBserver.
>
>
> If I have a piece of HTML that looks like this:
>
> <FORM ACTION="http://my.server.com/LoginServlet">
> <INPUT TYPE=TEXT NAME="username">
> <INPUT TYPE=TEXT NAME="password">
> </FORM>
>
> ...then how does my webserver know that authentication should take
> place? I fail to see how this is possible.
What I said above walks for HTTP basic authentication and Certificate based
authentication (SSL). Your example deals with form based authentication. In this
case there is a hole in the Servlet spec. "The LoginServlet needs some way of
communicating these security attributes to the web server environment". I hope Sun
people are monitoring the list. I sent the same answer in my last mail to the list,
here ist the chunk.
<Laird>
===> MAGIC PART STARTS HERE
LoginServlet now somehow magically calls God down from the heavens to
cause a miracle to happen whereby the EJB container that hasn't yet been
invoked is now made aware of the fact that Joe is the current
Principal. That is, any enterprise bean that, in the future, will call
EJBContext.getCallerPrincipal(), will get Joe's Principal as the return
value. Various angels and demigods retreat back to the ethereal heights
whence they came.
===> MAGIC PART ENDS HERE
</Laird>
servlets need a portable way for communiting form-based authentication data to
the webserver (basic authentication and certificate based authentication are done
by the webserver).
Regards.
--
Francis Pouatcha
MATHEMA Software GmbH
http://www.mathema.de
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
