ASP
  Home arrow ASP arrow Page 3 - Apply Single-Sign-On to Your Application
ASP Free Forums 
.NET  
ASP  
ASP Code  
ASP.NET  
ASP.NET Code  
BrainDump  
C#  
Code Examples  
Database  
Database Code  
IIS  
Microsoft Access  
MS SQL Server  
Visual Basic.NET  
Windows Scripting  
Windows Security  
XML  
ASP Web Hosting  
ASP.NET Web Hosting 
Dedicated Servers 
Moblin 
JMSL Numerical Library 
Windows Web Hosting
 
IBM® developerWorks 
Sun Developer Network 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ASP

Apply Single-Sign-On to Your Application
By: Softwaremaker
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 88
    2003-12-23

    Table of Contents:
  • Apply Single-Sign-On to Your Application
  • Sign-On: LDAP as the Key
  • What are the Pitfalls?
  • Two Solutions
  • Conclusion

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
    ADVERTISEMENT


    Apply Single-Sign-On to Your Application - What are the Pitfalls?


    (Page 3 of 5 )

    What are the Pitfalls?
    Of course, the concept of Single-Sign-On in Identity Management has its critics. The most important flaw is that once a user signs-on at point of entry, she is signed-on as long as she is in the company's domain. Theoretically speaking, if she does not log off from her machine, the session will always be authenticated regardless of who uses the same session later. In other words, while the user identity is not compromised, the current user session can be hijacked. This can easily happen when the user leaves his/her machine unattended and another person takes over the computer and the session. The main criterion of Single-Sign-On is that the user will only need to sign-on once (as the name suggests) and, therefore, there should not be a logout button. Having one serves no purpose as it is the session that is authenticated, not the user anymore. The user only serves to create a valid session. If there is a login after a logout, then the rule of Single-Sign-On is flouted.

    Another flaw of it includes the authentication of the user when the user is coming in from across another domain. This will likely happen if he or she uses the same application via an Internet Interface with the same application sitting on the office domains. The user can be in her own personal domain from home, elsewhere, or using another person's machine. Her own personal user-credentials will be different from the one that is stored in the organization's domain. This will require users to perform multiple logins, which goes against the concepts of Single-Sign-On.

    Some of the flaws can be solved by user-education. Educate the users to protect their machines whenever they are not around by locking up their sessions with a password-protected screen-saver or by other similar means. As of the second flaw, until an accepted secure and accepted tunneling protocol follows the user wherever he or she goes, that ideal may still be a way away.

    What are the Benefits?
    The benefits of using a Single Sing-On system are numerous. User-rights, coupled with user and company policies are all centralized in a single place within the organization directory. Users have only one identity (user IDs and Passwords) to maintain. Business owners will have the peace of mind that all entry points to applications and data are kept within a secure LDAP Directory with the company's user policy and password-policy in mind. This should be dictated by the business owners, not by the software vendors.

    Different applications will all query one single user directory for their own authentication and should they require more application-specific data and fields, redirect the user to collect more specific information from them. The storing of other information will ultimately be mapped onto the user common name in the LDAP Directory.

    More ASP Articles
    More By Softwaremaker


     

    ASP ARTICLES

    - ADO for the Beginner
    - ADO.NET 101: Data Rendering with a DataGrid ...
    - Introducing SoftArtisans OfficeWriter 3.0 En...
    - Getting Remote Files With ASP
    - The Real Basics of Functions in ASP
    - Enhancing Readability with ASP
    - Mimicking PHP's String Formatting Functions
    - Windows Server Hacks 12, 77, and 98
    - How to Sort a Multi-Dimensional Array
    - Developing an Information Management Tool wi...
    - What are Active Server Pages?
    - Getting Remote Pages with ASP
    - FTP’ing Files with ASP
    - Apply Single-Sign-On to Your Application
    - Easy Error Management





    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway