Hi, Tim
Our servlet has nothing whatsoever to do with Servlet-2.x style
authentication. We only have one servlet, and our application model is not
predicated on having umpteen JSPs and content pages to jump around to and
set security constraints on. We don't use a jndi.properties for
authentication.
The servlet is dumb, and is primarily concerned with being there as a known
point for receiving requests and issuing responses. There is no great
mystery revealed by indicating that we have an event-based application;
security is naturally event-based (i.e. "You in this role can either send
this event or you can't") from the user viewpoint. Logging in is just
another event - we typically use a form but _we_ create it, and the gathered
username and password are just strings being passed further down into
programmatic RoleManager code (roleManager.login(), in other words).
Our approach to security, IOW, is along the style of isPrincipalInRole(),
not EJB-style fine-grained method permissions. We consider this latter to be
nice in theory but not much use in practice, since it doesn't correspond
well to the granularity of what users do.
Could we set method permissions? Of course - the user is always in some
role, and we are controlling what role they are in. We just happen not to
use this form of security. I might add that the interface to the servlet,
because of an event-handling approach, exposes very few methods and they are
not suitable for EJB-style method permissions type security control anyway.
As far as the problem of N users hitting 1 servlet, if you're doing what we
do then there is no confusion. You end up writing your session management
anyway, to ensure that the servlet, for a given user, is handling off the
requests to a valid and correct SB. The SB in question can retrieve the
correct Principal as required, based on username, and do the role check.
You'll understand that we are using 100% programmatic user management. Also,
I think (in your last few paras) that you are close to answering your own
question. If you've got multiple users and you cannot rely on a
jndi.properties, then by exclusion you must rely on the users to supply
their identity. We use a form to gather the username and password when we
need them; client certs would also work.
HTH, Arved
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
Sent: Tuesday, November 21, 2000 7:07 PM
To: Orion-Interest
Cc: Arved Sandstrom
Subject: RE: -- Arved -- Can you please help me with servlet
authentication?
Hi Arved,
> Although we have a single servlet front-end, and do programmatic
> usermanagement (including login), the actual user manager and role manager
> stuff all happens down in EJB-land (in a session bean being referenced
from
> the servlet). So we do not use JNDI properties at all for authentication,
> except for some secondary application clients.
Are you saying that you simply ignore EJB-based permissions, and manage all
of the access internally in your session beans? This is the approach that I
want to take, but I want to be sure that only my servlets can actually get
to the methods that establish the "user session" upon which all else
depends.
Or are you saying that the servlet hands requests to Session Beans, and then
the SBs are changing the principal via RoleManager.login()?
> So I'm sorry if I gave the wrong impression. Based on user input, the
> servlet is telling the EJB (and dependents) when usermanager things need
to
> be done; the servlet is not actually doing that itself.
Again, are you using your own permission management, or are you using the
EJB permissions? Or are you just talking about user "management"
(add, remove, etc.)?
I am trying to establish user method permissions, not managing users, and I
can not get that to work at all.
> Incidentally, the JNDI lookup that works just fine here is precisely:
>
> roleManager = (RoleManager)new
> nitialContext().lookup( "java:comp/RoleManager" );
Ah! I will try that. Thanks.
> I might add that we are using the EJBUserManager, and we have found that
the
> programmatic control of groups doesn't work properly, so we hacked a
> workaround (concern when updating or adding users). Otherwise everything
> described above is cool.
Well, this now suggests to me that you are using EJB permissions. Are you
calling RoleManager.login() to change the principal from what the servlet
had established via jndi.properties?
> Assuming you figure out the jndi.properties thing, then you ought to be
able
> to obtain the principal name and the credentials (password) from the
> environment, and pass that info into a session bean that can actually do
the
> usermanager and role manager stuff. IMO.
This is very confusing to me. If I have N users hitting 1 servlet, and that
servlet is establishing the principal from jndi.properties, how in the world
do I establish the user for EJB permissions? When that servlet accesses a
session bean, the SB will see the user from jndi.properties, not the user
that
is driving the servlet. How do you work with that? RoleManager.login()?
In my opinion, this is one of the most critical and least understood aspects
of Orion, and the most poorly documented. I get the impression that no one
is
doing any serious user management. Or they are not sharing how...
I would like to cut a check for Orion, but I need to confirm that it will
support our needs, and permissions and performance are the last things I
need to verify.
Thanks again,
tim.
