• Post Reply Bookmark Topic Watch Topic
  • New Topic

Am I missing something?  RSS feed

 
Val Pecaoco
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,
For over two years now, I've done all of my applications requiring logins to use simple database authentication. It's just basically taking the user's username and password and checking it to see whether it exists in the database.
But I feel that I'm getting old for this. And times have also changed, since nowadays the norm is for applications to have different roles and levels of access fostered on its users. Typically we see this type of requirement in portals. My simple database authentication scheme is already being stressed out.
I feel it's time to move on to keep up, but what to do? I've heard a lot things, like LDAP, single sign-on, JAAS, etc., even proprietary extensions to products, like Oracle9i. Basically I need advice on how to approach these technologies.
Thanks in advance. Ex Animo Java!
-- Val
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Depending on what you want, one option is to use the "standard" security mechanisms that are a part of the J2EE. For example, with Servlets/JSP, you can define a collection of users and use functionality provided by the container to authenticate users by various means such as basic HTTP authentication, form-based authentication and so on. In fact, you can even use things like certificates. This is well supported and you'll find lots of documentation about in the specs and books.
The other good thing about using this type of mechanism is that is abstracts security away from the application. In fact, much of this mechanism is declarative, meaning that you don't have to write any security (authentication and authorization) code yourself.
Hope that helps as a starter...
Cheers
Simon
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Isn't the inherit problem with using the built-in J2EE security of an Application Server vendor ties? The problem is J2EE only defines a standard for declaring permissions, not for creating and editing users and groups.
One is going to have to use the vendor supplied API for common tasks such as creating new users and changing passwords and that means coupling with the Application Server. Of course, this effect can be minimized by isolating the code through the proper use of patterns but it still requires additional coding to move between application servers (assuming the new application server even provides the same type of functionality).
Then you run into situations where the client wants the ability to create groups and assign permissions dynamically. The J2EE specification has not even begun to try to address these types of issues.
I find there are still many cases when I need to roll my own security for J2EE applications because of the limitations of the current spec.
[ September 15, 2002: Message edited by: Chris Mathews ]
 
Val Pecaoco
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,
Thanks for all the replies. The picture is quite clearing up, but I think I owe you a more detailed picture of my dilemma:
I'm working on our company's intranet and its quite obvious that it's shaping up to be portal, something with discussion boards, Web mail (coming soon), plus enterprise apps like retrieving of branch reports (because I work in a bank and branches need a daily extract of reports from our CA/SA), and even a data entry site for a raffle promo our bank is holding. Then add in the admin sides for all of those and it'll be quite messy. In short, its a smorgasbord of disparate apps with users' rights and privileges of access overlapping in between. And sometimes it's not just a single user, but a group of users with one level of rights (say, tellers of branch A).
It's a typical scenario, right?
Now the users' authorization (username/password) is done against the database. So it means that every user has a username/password pair for every app! Sesh, certainly making a single, bloated table where all the usernames/passwords/rights are stored is out of the question.
Before it all implodes, I'm thinking of doing it prmarily with LDAP, then perhaps blend in some standard security mechanisms like certificates or JAAS.
I need your help in determining the best combination. In another light, what would be the best design pattern? Currently it's done with Struts.
Again thanks for all your opinions! Ex Animo Java!
-- Val
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!