• 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

How does LDAP relate to security?

 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I have the general idea of what LDAP is - a (standard?) protocol for accessing a hierarchical registry, primarily used for user information management.
What I am wondering is how do LDAP products provide security? I guess they encrypt the data within but is the access protocol itself encrypted?
How do I use an LDAP directory from Java? Through JNDI, if so then which properties do I need to give when creating the InitialContext?
[ March 18, 2003: Message edited by: Lasse Koskela ]
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To me, LDAP + security = SSO.
If I remember correctly, LDAP allows SSHA for security. LDAP administrators can chose to store passwords as clear text or encrypted form.
If your ou already stores the entire employees' info in a LDAP. The next logical thing to do might be extending the SSO mechanism with it. Then employees can access various resources without the hassle of remembering too many passwords/pins.
What I meant was, tieing the LDAP to the intranet & any other resources that you want people to have access to. But of course, we need to implement access control to keep certain areas out of bounds.
Hope this helps.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Cheng Wei:
Then employees can access various resources without the hassle of remembering too many passwords/pins.


So "single sign-on" actually means "multiple sign-ons with a single username/password"? How is single sign-on usually implemented if an enterprise has several entry points to their systems (i.e. there is no "portal" through which all requests come in and which could perform authentication against LDAP)?
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

What I am wondering is how do LDAP products provide security? I guess they encrypt the data within but is the access protocol itself encrypted?


The hierachical model of LDAP seem to fit well with typical organizational/security model, i.e. directories provide for access control, effective rights, certificate (PKI) framework and encryption.
I said a lot of things, but in a nutshell, you can store security information in an relational database (like Oracle), but will have to do more work to compute effective rights, and manage various stuff required to provide good security.
It is not to say that databases cannot be used, but just that LDAP enabled directories blends itself to provide for user profile and security infrastructures.
Rama
 
Rama Raghavan
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

To me, LDAP + security = SSO.


I'd use extra caution with such a statement..
Let me talk this thru as I work it out backwards:
SSO (Single Sign ON) - Ability to login just once, and still be able to access multitude of applications/resources with appropriate access.
Lets say I access a URL for the first time, then I am prompted with a challenge/response to enter my user ID and password. Subsequently, when I navigate thru the site, when I move from Customer Care to Inventory Control to Financials, I should NOT be prompted for userID/password again (since I have already logged in). However the system should (behind the scenes) constantly check if I am authorized to access a certain URL/resource and what is the level of access (read/update/delete).
To grant access to a certain resource, usually there are some administration functions/utilities/screen that can be used to setup access.
If the above scenario is accomplished, then as a user I was Authenticated (validated for userID and password just once), and granted Authorization (access) to various resources.
So, in my opinion:
One (and only one) Authentication process + Authorization (to various resources appropriately) = SSO
Rama
 
Rama Raghavan
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

How is single sign-on usually implemented if an enterprise has several entry points to their systems


Typically you would develop a "plug-in" and install/configure onto the web server. So when a user first accesses any resource on www.enterprise.com the plug-in will have the smarts to check if the user has been authenticated, if not prompt for credentials.
If the plug-in found that the user was infact authenticated, then it can check if the user is authorized to access the requested resource (url).
So you can secure www.enterprise.com/customercare and www.enterprise.com/financials by configuring a plug-in to the web server (www.enterprise.com).
Now - if you have the skills and time, YOU can build the plug-in to have such smarts, or if you have the money, then buy industry products such as Novell-SSO, Oblix, Netegrity or plethora of other products.
Rama
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rama Raghavan:
One (and only one) Authentication process + Authorization (to various resources appropriately) = SSO


Great. That's what I was thinking too, but how is this typically accomplished? Is the incoming request required to contain a session ID, which can be used to locate a username and password, which in turn are used to authenticate and authorize access the resource.
Does SSO work with two simultaneous terminals? Meaning that if I browse a company intranet with a web browser (first sign-on) and, while waiting for something, use my Java-enabled phone to browse the company address book, does the SSO-stuff eliminate the need for me to authenticate with my phone also (second sign-on)?
 
Author
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Actually, the SSO between applications is generally accomplished in different ways by different products. In the policy server space, session tracking across applications was generally done either with cookies or (when using SSL) using the SSL session ID. I always found the later way less reliable, but I know that Tivoli used to tout it a lot with their Policy Director product because a lot of people were paranoid of cookies. The cookie itself just contained session id information anyway, which of course could be submitted by the agent (for an agent-based product) or captured in the middle by a more proxy-like policy server.
Either one of those capture points would simply present that information back to a centralized server (or servers) to get any required user-related information. The server could also attempt to answer authorization-related questions at that time.
The trick with any SSO type solution is usually the presentation of credentials to an end service. In many cases this is simply done by asserting an application's credentials to those places and having actions performed as the application, rather than as the user, and have the application do access control. Another way I've seen this done is by storing a masked version of the password so that it could be unmasked and presented to the end service in order to authenticate as the real user, but I've always thought this was more of a security risk than it was worth.
As far as LDAP goes, many times LDAP is used not so much for single-sign on, but for providing a single set of credentials for a variety of applications. This may require that users enter their credentials multiple times, but those credentials will be the same between applications, which reduces the number of passwords to memorize or synchronize. This is obviously a lot easier to implement as it doesn't require deploying policy servers and such, though obviously it's not quite as convenient to the end user.
Clayton
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That was quite an elaborate answer, Clayton. Thanks.
If somebody can refer me to a source of tutorials/technical whitepapers about SSO-products or implementations (preferrably with applications developed in Java), I'd be very grateful.
Novell-SSO, Oblix, Netegrity were mentioned by Rama earlier. I know Netegrity costs a gazillion. Are there any viable low-cost products in the market, open source perhaps?
I thank you all for the effort.
[ March 19, 2003: Message edited by: Lasse Koskela ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic