Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
Bartenders:
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Is it still good to use single sign in today world ?  RSS feed

 
Ranch Hand
Posts: 496
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello experts,

I am now at a stage where I need to implement a secured log in for my web-app on a site which is SSL secured.

However, before I launch into things, I would like to know if single sign on using Tomcat with jsp and servlet is it a good solution ?

Are there other secured log in I should consider to work with tomcat, jsp and servlet or REST?

Thank you for sharing in advance.

 
Bartender
Posts: 20742
124
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, SSL-encrypted and "secured' are two different things. To be secure you almost certainly need a secure transport channel, but you also need security constraints to protect sensitive resources. For that you need 2 things: Authentication and Authorization.

Authorization simply means what you can or cannot do. But in order to be able to tell who can do what, you need authentication so that you know who is whom. If I claim to be Fred and go on to do things that only Fred can do, that's not authentic. So the authentication mechanism makes me prove I really am Fred.

In the J2EE container security standard, authentication is done by the webapp server, not by the web application. The server detects secured URL requests (matches a security pattern in web.xml), checks to see if the request submitter has been authenticated, and if not, diverts the URL request and initiates login using a loginform or dialog. Only after the user has successfully logged in will the original request be allowed to continue.

Note that since the container manages the login process, there is no login code in the web application. Instead, authentication is handled by plug-in modules called Realms. The Realms also check role requests to see if a user is allowed to act in the requested role.

SSO is a special type of Authentication where the user logs in once, and all other apps will accept that identity instead of making the user log in to each application separately. It can make life a lot simpler, and if you're using a dashboard-type application whose content is an amalgamation of requests from other apps, it can be very valuable (imagine a page where each frame had a separate login screen!).

Since Tomcat Realms are plug-replaceable without the need for application modification, you can easily switch from SSO authentication to one of the other Realms such as JDBC or JNDI (Active Directory).

While I do recommend the standard container authorization for most webapps, ReST apps can be a bit of a problem, since they're not really intended to work with a human operator, so the usual login screen is not a good fit. In such cases, there are other options, but I'll leave explaining them to someone else.
 
tangara goh
Ranch Hand
Posts: 496
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you both.
Now, I have just come to know that the web hosting company take control of the Tomcat server - as in I can't start and stop Tomcat on my own, even though I am subscribing to a private instance of Tomcat server.

How will the authentication and setting of realm keep things private?

All all other web hosting companies work the same ? as in usually the control will be with them ?  
 
Tim Holloway
Bartender
Posts: 20742
124
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most hosting companies these days will rent you a complete VM, so for such cases, you would have control of Tomcat. However, some, like some of the more specialized services like Amazon's Elastic Beanstalk might do what you said.

In any event, you can define the Realm for a Tomcat webapp in the webapp's deployment descriptor. So unless they also don't let you deploy your own webapps, that's all you need.
 
tangara goh
Ranch Hand
Posts: 496
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:Actually, SSL-encrypted and "secured' are two different things. To be secure you almost certainly need a secure transport channel, but you also need security constraints to protect sensitive resources. For that you need 2 things: Authentication and Authorization.


In the J2EE container security standard, authentication is done by the webapp server, not by the web application. The server detects secured URL requests (matches a security pattern in web.xml), checks to see if the request submitter has been authenticated, and if not, diverts the URL request and initiates login using a loginform or dialog. Only after the user has successfully logged in will the original request be allowed to continue.

Note that since the container manages the login process, there is no login code in the web application. Instead, authentication is handled by plug-in modules called Realms. The Realms also check role requests to see if a user is allowed to act in the requested role.


Since Tomcat Realms are plug-replaceable without the need for application modification, you can easily switch from SSO authentication to one of the other Realms such as JDBC or JNDI (Active Directory).

While I do recommend the standard container authorization for most webapps, ReST apps can be a bit of a problem, since they're not really intended to work with a human operator, so the usual login screen is not a good fit. In such cases, there are other options, but I'll leave explaining them to someone else.



Hello Tim,

I'd like to clarify the part about using container managed log in via REALM, cos there are so many types as I read from Tomcat server official page.  Can I know if I choose the most BASIC one will the protection be sufficient ?

Cos the password in the database would be exposed anyway .... what are the security measures one can do to prevent this kind of exposure ?  

 
Saloon Keeper
Posts: 5480
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

tangara goh wrote:I'd like to clarify the part about using container managed log in via REALM, cos there are so many types as I read from Tomcat server official page.  Can I know if I choose the most BASIC one will the protection be sufficient ?


Which one do you reckon to be the most basic? As the docs state, user database and memory are not meant for production use. JDBC or DataSource would be fine, and are easy to use.

Cos the password in the database would be exposed anyway .... what are the security measures one can do to prevent this kind of exposure ?  


What do you mean by "exposed"? That word usually indicates a security breach, which -obviously- you want to void.
 
tangara goh
Ranch Hand
Posts: 496
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because it is residing in the database therefore it is still being stored. So, ‘exposed’.

I wonder why people used salt with password because it is pair with the passwords and stored together in database as well. I hope you can share your opinions on this too. Thanks again.

 
Tim Moores
Saloon Keeper
Posts: 5480
143
Android Firefox Browser Mac OS X Safari Tomcat Server VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The password should only be stored in the DB in hashed from - so it can never be seen in clear text. That's not exposed.

As to how salt provides additional protection, start with Salt_(cryptography). It only makes sense along with hashing: https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification. That also explains why the salt can be stored together with the hashed password.
 
Tim Holloway
Bartender
Posts: 20742
124
Android Eclipse IDE Java Linux Redhat Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The worst offence is when a login routine does something like "SELECT USERNAME, PASSWORD FROM USERS WHERE USERNAME=?". Well short of actual injectable SQL, anyway!

This is bringing the password out of the database server and into the application server, meaning that in order to harvest the password you only have to hack the application server, which is more directly connected to where most attackers live.

Encrypting the password while still using this form is only marginally less secure. Even encrypted passwords get sold freely, since there's always the possibility that the purchaser may figure out how to crack them. Hashed passwords are little beter, since actually there are more solutions for a hash than for straight encryption, unless it's a perfect hash.

A far safer solution is "SELECT COUNT(*) FROM USERS WHERE USERNAME=? AND PASSWORD=?". This keeps the actual password on the DBMS server and at worst attackers on the application server can only watch passwords being submitted and look for results where the returned value is >=1 (password matches). That essentially eliminates the strategy of submitting a bogus signon just in order to get a copy of the password from the datbase.

Truly paranoid systems will use a different database connection (with different DBMS user/password) for password checks so that application code cannot query the USERS table themselves - or, where the DBMS internal security is granular enough, maybe allow access to some USERS columns, but not the USERS.PASSWORD column.

Additional evil strategies can be employed as well, but don't go overboard, the more convoluted a scheme is, the more potential loopholes. And, like the people who check receipts at the shop door, you can end up costing more than you save (I don't shop at places who treat me as a shoplifter first and a customer second, no matter HOW much the savings).

Note that in single-signon, the actual webapp you are talking to might not be the app where you first logged in, especially if your SSO is tied to your OS user identity (Windows login, for example). In such a case, all participating apps are talking back to a central authority - often using something like Kerberos tokens. So your webapp would never present a login screen or login dialog, but the HTTPServletRequest would still have a userid in its getRemoteUser() and getUserPrincipal() return values.
 
I can't take it! You are too smart for me! Here is the tiny ad:
how do I do my own kindle-like thing - without amazon
https://coderanch.com/t/711421/engineering/kindle-amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!