Hi,
Regarding security, the JSDK spec is IMHO too simple and that has forced
many people to reinvent the wheel again and again, or get into
proprietary solutions. We chose to go our own way to be fully portable
and we end up with such a system:
.- As we already have implemented a Model 2 architecture with a servlet
controller, it was quite easy to decide where the security checks would
be performed, that is, the controller servlet.
.- To have an architecture that was also portable between applications
and avoid copy/paste, we developed our security mechanisms(SM) using
basically abstract classes and interfaces. This allows us to secure an
application just by implementing the appropriate classes, which can be
done apart of the business logic.
.- We distinguish two parts: Defining the security environment of the
application(users, roles...) and defining the security requirements of
the applications operations(which roles are required for each request).
.- For the first problem we provide a set of interfaces to define the
users and roles at initialization time, to be stored in a cache (we also
already provide an XML-based implementation that can be used for simple
applications out-of-the-box and works from a file, URL or a database).
.- For the second we wanted the ability to set the security constraints
in runtime. So we implemented the SM so they ask for each request,
through the interfaces, which is the requiered permission to perform
such a request. As the application implementation is passed the request
and the context, it can decide the required permissions depending on the
parameters, the URL, some values stored in the servlet context...
.- We also provide a "dynamic" setting in which we just pass the
username/password and request to the application implementation and it
has to answer back if the request is allowed or not. This feature is
useful when you have too many users and they won't fit in the cache, or
they change very often.
The trickiest part to implement was the cache of sessions as we wanted
to allow basic and form authentication and be able to log out, detect
simultaneous sessions... Handling all that with the various browsers
behaviours was not a simple task, but once done...
But the key point is that it is a proprietary mechanism that we have to
mantain and update, and I don't think we should do it. If the standard
was complete enough, something like that would be specified in a
portable way and every container vendor would provide such a service,
thus making applications really portable. The proof to see that the
standard is not complete is that evey container vendor has its own
implementation. To be truly portable, you have to roll your own, but I
wish I hadn't to.
Just my 2ec,
Dan
PD: BTW, we are not a porn site either ;), just tired of copy/pasting
the same security routines over and over and...
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
David Morton wrote:
>
> I am building a system that protects content by username and password. No
> problem there. The more complicated part of the system prevents two people
> using the same username and password at the same time on our web site. I
> have a plan to do this, but I haven't seen if there are any common
> methods/techniques/strategies/design patterns to do this in a jsp
> environment. Nor do any of our developers have any experience in doing this.
> Currently, I am just going to store server generated sessionId's and
> userId's with other necessary data/time checks......of course the user must
> be able to take over use of that username and password because the browser
> may crash...or they forget to hit logout....and also I must flag when this
> happens too many times in a period of time as a red flag....obviously with
> an html web site, there is no 100% accurate way to only have one user using
> the site at once, however, I can build it well enough that 95% of the users
> that are giving out their passwords won't because it is annoying to keep
> re-logging in and being locked out for an hour if you trip one of our red
> flags.....thoughts? experiences?
> This is not for a porn site, however, I bet that porn people have
> something like this.
>
> David
