• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Custom Java form login Filter vs 'blackbox' approach (JAAS, j_security_check, etc)

 
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, this is more an general enquiry than anything...

This isn't fully working code; in fact it was written quickly so is more pseudo code than real code.

I'm just wondering, from a 'stupidly simple' user login point-of-view; what do JAAS, j_security_checker, Shiro etc do
which this doesn't (excluding Realms for now, will look at that later.)?
Why would (if at all) this be an unsecure (ineffective) method of simply checking a user's username/password and allowing them
to a secure page if authenticated, else redirecting them to the login screen. By that I mean is there a way you could do XYZ and always be authenticated.


The URL

web.xml

Example Filter


Cheers in advance

 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A topic dear to my heart :-)

For starters, it's important to remember that the various security solutions you mention have somewhat differing purposes and capabilities.

  • yours: authenticate users of a web app


  • j_security_check a.k.a servlet security: authenticate and authorize (A&A henceforth) users of a web app. Authorization means each users can have different roles assigned, although that's used much less in web apps than the authentication part.


  • JAAS: a general A&A solution for Java. It can tie into servlet security (witness Tomcat's JAASRealm), but is not a really good fit; see Using JAAS in Java EE and SOA Environments for some more information on that. It's more commonly used in desktop apps and app servers than in servlet containers. It has a lot of extension points, so it can be made to work with just about any A&A approach, including hardware devices and non-Java processes.


  • Shiro: a library that implements a lot of functionality you'd need for A&A in all Java environments (not just for servlets), but also cryptography and session handling (also independent of servlets). This is what I would use for just about any new project, or any project where security needs to be substantially reimplemented.


  • Why would you use any of these over yours? Because, with all due respect to your coding ability, security is very hard to get right, and very easy to implement in a way that leaves your system open to attacks. It's much better to use something tried and tested, not to mention the savings in development time.
     
    Kevin P Smith
    Ranch Hand
    Posts: 362
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Ulf,

    Yes I noticed you replied to my post a few weeks back about JAAS and if it was worth the effort.

    I think j_security_check would be the closest fi to what I'm looking for (basically a simple login, but with some 'roles' witin the the admin side of things).

    There are although, a couple of issues I have with j_security_check.

    1:
    Plain text! Now maybe this isn't an issue at all, but I have always encrypted (MessageDigest) passwords. I can't see a way to do this with j_security_check, in fact it seems to work with clear text passwords.

    2:
    Going straight to a login page. j_security_checker is great for attempting to access a secure page, but if the user goes to a login form?


    NOTE:
    Actually on point 2, I suppose my 'login' link could try to take the user to their 'homepage', then it would goto the login screen first and then redirect to the 'homepage'.
     
    Ulf Dittmer
    Rancher
    Posts: 43081
    77
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kevin P Smith wrote:1: Plain text! Now maybe this isn't an issue at all, but I have always encrypted (MessageDigest) passwords. I can't see a way to do this with j_security_check, in fact it seems to work with clear text passwords.


    There are two parts to this: encryption in transport (i.e., using DIGEST auth instead of BASIC auth) and encryption in storage (storing digested passwords in the DB or wherever instead of cleartext passwords). The mechanics will differ between servlet containers, but for Tomcat both are discussed in http://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#Digested_Passwords

    Going straight to a login page. j_security_checker is great for attempting to access a secure page, but if the user goes to a login form?


    That's not how servlet security is meant to work - the login page is only used en route to a protected page, not as an entry page itself. So there should not be a link to it anywhere. I'm not sure what happens if a user goes there directly - he may be redirected to the home page after login.
     
    Kevin P Smith
    Ranch Hand
    Posts: 362
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You've touched on point 2 with this person too.

    https://coderanch.com/t/441617/Servlets/java/security-check-login

    I think if you go directly to the login page and login, you get redirected to.... the login page! :-)

    So I thought maybe my login link could actually try to take the user to their ./secure/homepage page, that would sort of work around it.
    reply
      Bookmark Topic Watch Topic
    • New Topic