I have read about LDAP on wikipedia and I kind of understand what it is. However what I did not get what why so many organizations are using LDAP authentication server over having a simple table with userid and hashed password.
LDAP server surely brings more complexity to the infrastructure. What gains justify this added complexity?
LDAP is complex, but it brings a lot more to the table than just centralized authentication. For example, many email clients can be hooked in to do LDAP searches to find other users - i.e. look up an employee by name, find their email address and phone number right from your email client.
Also, it is extensible - you can define your own types of objects and store them in the directory, so it can be used to store even data that the original implementers did not have in mind when designing it.
For example, OpenSolaris (and therefore I presume Solaris) machines can grab significant amounts of their own configuration over LDAP.
While setting up LDAP is not for the faint of heart and it makes little sense for the home user / small smattering of machines, the aggregate savings over thousands or tens of thousands of computers can make it worth it if administered properly.
Using a simple table seems like a good start until you need to use that same username and password in other locations. When your other systems (email, code, server login, bug tracking/ticket systems, etc.) start getting into the mix and you need to maintain all of them the table approach will be unmanageable fast because you would have to write an adapter for all of them to connect to your table for auth. Using ldap which is a standard and used by many projects will make it easier for you to maintain
Table with name and hash does not define an authentication scheme, it just defines a storage for the credentials. Authentication involves a protocol for the user to proove it's identity, like Kerberos or HTTP Digest. Organizations that deploy ldap don't, t deploy it for auth per se, they use Kerberos for that. Ldap is used for things like user organisatinal structure management (OU) or asset inventory. Once you deployed Kerberos for authentication and autheization it makes sense to use LDAP as your organization structure store, since most kern implementation will create an ldap anyway, eg. NT domain controllers.
At an application level..
In a Windows domain environment it can make sense to use LDAP as a means to use existing Active Directory information instead of duplicating all of your authentication.
Related
I have the following scenario.
At my company we use Oracle 11g. The authentication on the frontend is using database users. So, every user of the frontend has a his own user account in the database system.
This implies that they have the ability to connect directly to the database, if they know the IP address, port, etc,. Of course, this is not considered a security concern because our strict managment of roles and privileges. This also implies that when a new user is added our DBA have to create the user and assing the proper roles and privileges.
Until now, our frontend is accesed only by our internal users. However, We are planning to add the capability for our external users can login in our frontend.
Our estimation is about 750,000 external users with annual increments of 50,000. This users are supposed to access our system three or four times per year.
The question we have is how to grant access to this users.
By using our already implemented authentication system. Every user has his own database user account.
Generating an authentication system for external users only. Like most of the CMS's in the market, with tables as an ACL (Access Control List) for users, passwords and roles for our 750,000 external users.
My main concern is to have +750,000 database user accounts that will be unused most of the time and eventually could make a mess with our internal users.
Someone have a similiar experience with this amount of users and how did you deal with it?
Best regards.
Off the top of my head..
Make sure that whatever outward facing boxes are few in number.
For the boxes that can connect to the database - make them purely
authentication or get/put for the data. don't run the web server on the databases or on the same LAN segment.
If possible encrypt communications from the client to the database so that if any of your intermediate hops get rooted they'll only see junk.
Use a firewall to ensure that only the bare minimum can get through.
For validating authentication, don't let their 'real' password get off the web server. Keep it hashed, San Diego!
I have an AIR application and would like to connect to an LDAP server to obtain some information for a particular user.
The url is something like ldap://ldapservername:389/
I would like to pass the userid/Name as the parameter and hope to retrieve the Full Name, Email address etc.
Can you please provide suggestions regarding implementing this? A Windows specific solution is also fine with me.
Adobe AIR does not have built-in support for LDAP. All online examples go through a server for LDAP integration.
Sample: Performing an LDAP query for role resolution
http://www.adobe.com/devnet/livecycle/articles/perform_ldap_resolution.html
Short of using a server, you're limited to two options, neither of which is good.
Completely re-implement the LDAP protocol in AIR. I think this is feasible, but is a huge undertaking. With Alchemy you theoretically could recompile an existing C library to work with AIR, but I don't know how well that will work for this particular use-case. Plus it's a research project, not production ready.
Embed a native application. With AIR 2.0 you can include a native application written in C or .NET or whatever and launch it to perform your LDAP calls. The only way to communicate with this other process is through stdin/stdout so it's not easy to transfer complex/typed data, but it's feasible.
AIR is not suited for all applications. If all of your application's requirements can be fulfilled within AIR's API, then it's great. But if you need to do something not directly supported by AIR and don't have a server component, you're better off not using AIR.
You will probably need to do the usual LDAP stuff. Either start with the full DN of the user (uncommon) or search for it.
Bind to the LDAP directory as a proxy user, or as an anonymous bind. Query for ATTR=VALUE where ATTR is something you define as the unique value in the directory. Traditionally this is uid in LDAP servers. For Active Directory probably would be better to search for ATTR of sAMAccountName. Keep this as a setup parameter for the admin, since it will make it easier on different LDAP backend servers.
It might be mail, and the login value the user would enter is their email address. Depends on the use case. But leave it configurable to be flexible.
Then the search should return one value, with a full DN, then you want to bind as that user with the full DN and the provided password. I like the approach of binding as the user, instead of comparing the password, since then you increment any Last Login attributes, or the like, making it easier to detect account inactivity from the directory administrators perspective.
I have to start a new project where user authentication/management will be required.
A lot of websites use existing authentication mechanisms like facebook/twitter/openID/google/etc (even SO).
While I might understand that they are used to simplify some parts of this workflow can someone enumerate the pluses and minuses of using one of these authentication mechanisms vs. an usual user creation and what should I look for when I do this?
Thanks in advance!
Here are a few:
Advantages of using external auth (like openId)
For the user, fewer account names/passwords to keep track of
For you, don't have to manage password resets etc.
Disadvantages
Ties you to an external service (if google/facebook is down, so are you)
Your site is only as secure as the external site(s) you trust as id providers
I am working on a system architecture for a fund/pension manager. We are providing two ASP.NET MVC web applications; one to allow members of the pension fund to login and check their balances, manage their investment, etc and another to allow employers to make contributions to the fund on the employees (members) behalf. There are also internal applications delivered via the intranet.
We have been considering using Active Directory for storing, authentication/authorisation of not just the internal users (who are already using AD for logging into the domain and resource authorisation) but for the member and employer user accounts. The member and employer user accounts would be located in a different hierarchy (maybe even a different AD instance?) to the internal users.
However I am wondering if this is the best use-case for AD... given AD is such an 'internal' resource, should it be used to hold auth details for 'external' users (the alternative being a USERS table in a database)?
The benefits are: AD is designed and optimised for holding this sort of data, ASP.NET apps integrate with AD authorisation easily, there possibly are existing tools for working with the data (password resets, etc).
What are the risks?
I would recommend against a hybrid of internal and external users. Speaking from experience it opens a lot of security headaches. It might be better to create separate authentication systems, one that uses AD directly against the internal domain and another that uses an ADAM directory designed simply to hold external users. (i.e. - internal users should be authenticated using NTLM with the AD to ensure a kerberos encrypted login, while forms would be usable for the ADAM instance).
AD is very easy to integrate though, and if direct integration is undesirable due to the networking lumps, you can always attempt an LDAP:// to achieve the same authentication results.
I think your biggest risk is that AD would not scale to the amount of users you might have from an Internet app. I would use the Membership provider, unless you are trying to achieve SSO with internal and external accounts.
I've been reading about Azure's Access Control Service and claims-based authorization in general for a while now, and for whatever reason, I still don't see the rationale behind moving from role/permission-based authorization to a claims-based model. The models seem similar to me (and they probably are), except that the list of what the client can and can't do comes from a third party and is wrapped up in some sort of token, instead of from some sort of database that the server has to query. What's the advantage of getting a third party (the token issuer) involved?
I fully understand the advantages of outsourcing authentication to a third party. It allows apps to not have to create new users all the time, worry about storing passwords, etc. when they can just push that off to some other service that already has the infrastructure set up. It's essentially the DRY principle for authentication.
However, in my mind, that same logic doesn't work for authorization. Each app has its own resources it has to protect, and therefore its own rules for authorizing users to perform certain actions. The infrastructure seems simple enough that each app could create it on its own (a table mapping users to roles, and possibly another mapping roles to permissions), and even if you wanted to outsource it, it seems that the claims-based model is doing something more complicated than that.
The only partial explanation I've seen comes from Building a Claims-Based Security Model in WCF, and it gives two main advantages to claims-based auth: more flexibility, and someone to "vouch" that the information in a claim is correct. When would you need either of those?
Claims-based authorization seems to be gaining popularity, so I assume there must be some good rationale for it; I just haven't figured out what that is yet. Can someone please provide a concrete example of a situation where claims-based auth works better than role-based, and why it works better in that case?
(EDIT: I missed a third benefit listed in the article: supporting single sign-on/federation. But doesn't authentication deal with that on its own without getting authorization involved?)
I guess the main promise of a benefit from federated security / claims-based system would be one fewer area you have to deal with different systems.
Imagine a site where you have local users authenticating with Windows credentials, a bunch of internet users using username/password, others using certificates, and maybe another group of users with biometric authentication.
In today's system, you have to set up and deal with all different kinds of authentication schemes and their different ways of doing things. That can get pretty messy.
The promise of a federated security solution would be to handle all those chores for you - the STS (security token server) would handle all different kinds of authentication systems for you, and present to you a uniform and trusted set of claims about a caller - no matter from where and on which path he's arriving at your site.
Of course, just examining and reacting to a single set of claims rather than having to understand four, five, ten different and disparate authentication systems looks like a really compelling promise to me!
The purpose of claims based authorization is to allow fine grained access control based on Boolean expressions that evaluate characteristics of the accessing entity and the resource. This reduces or eliminates the need to provision groups. As with federated identity, claims also provide a vehicle for an Identity provider to manage their users wile allowing a resource provider to gate users access to assets.
Note: Claims can be used within a single enterprise and provide the following benefits:
1) Access grants and revocations do not require provisioning or de-provisioning
2) Thus changes are instantaneous
3) Resource owners can define the scope and requirements for access rather than having admins create groups manage group memberships - this moves the access control decisions into the hands of the folks best suited to make such decisions (the data owner)
4) This results in fewer groups being required and fewer member in the groups
5) There can be issues creating a single group to accommodate a large community having access (for
example all full time employees can read a HR policy) - Claims avoids this problem
6) Audit is more informative - the reason a grant or deny took place is clearly visible
7) Claims support dynamic attributes, such as 2-factor authentication, time of day, or network restrictions
There are a lot more reasons, but those ones come to mind. There will shortly be a video at www.cionsystems.com that showcases this (disclaimer - I work there and recorded the video - I still need to post it) Also, for reference, claims aware apps and platforms include SharePoint 2010 on, Windows 2012 (file shares), Azure, many SaaS services (Facebook and Salesforce)
Also, with claims you can blend information from multiple sources (say Facebook and your local AD) etc. - which is increasingly important
Not sure if the rules allow this, but feel free to ping me with your questions or comments. I'll happily edit the post to make any corrections or add pertinent info.
Claims can come from AD, databases tables, SAML, OAuth, algorithms, XACML or any other trusted provider. Harnessing claims requires a bit of kit - with apps and platforms evolving rapidly in this space.
All the Best,
Paul
Claims-based access control also helps build up attribute-based access control and policy-based access control. If you standardize on a set of pre-agreed claims that can be assigned to users based on their other attributes (e.g. a US manager can have claim U_M; a European manager can have claim E_M).
In an attribute-based and policy-based environment, it's possible to achieve fine-grained authorization (also known as fine-grained entitlements) using XACML.
In this case, you can have authorization that depends on who the user is (claims) but also what they want to do (resource information) and under which circumstances (context).
CBAC with XACML will let you express rules like:
managers can edit notes they created themselves or notes that their
direct reports created.
Role based security is a limited security model
Authorization is:
Based on role membership only
Claims based security is much more flexible and expressive
Authorisation can be:
Based on role membership
Based on Age
Based on Geographic Location
Based on an account balance
Based on a size
Based on pre-defined securtiy levels
Based on any combination of the above