I am new to this terms.
So can anyone explain which is better for implementing authorization ?
Please also explain reason for the same.
It depends on your usages - but you seem a tad confused.
OpenAM is an open source Authentication, Authorization, Web SSO & Federation solution. OpenAM embeds OpenDJ which is what you'd be referring to however it can utilise other LDAP directory servers or can use OpenDJ Externally (which it is tailored for).
LDAP is a protocol used for accessing a directory. A directory contains objects; generally these objects are related to users, groups, and other things within the organisation.
OpenDJ & Active Directory are both Directory Servers. These differ from the LDAP protocol.
If you are looking for pros and cons of directory servers alongside a length definition i suggest a search of Stack Overflow for an already written answer on this topic or reading here:
https://www.ldap.com/choosing-an-ldap-server
Related
I'm looking for alternatives to running Internet Information Services (IIS) on Windows, but one of the requirements of this project is the use of Windows Authentication against a Microsoft Active Directory domain.
I've heard that NGINX supports NTLM authentication, per this blog post, but while it talks about how to set it up, it doesn't go into much detail about how this actually works for web developers.
I have a few, specific questions about how NGINX Plus + LDAP / NTLM support works for web developers:
Is it possible to perform user impersonation, similar to C# / .NET on IIS?
Is it possible to authenticate to other resources, from a web application, as the user that's authenticated?
Is it possible to obtain metadata about the directory and the user, such as the user's group memberships, or information about other users in Active Directory?
If the above is possible, are certain languages / frameworks better than others for performing these tasks, versus others?
I have successfully assembled over a half dozen passport strategies (facebook, twitter, linkedin, instagram, tumblr, google, youtube) exchange account info with oauth1 and oauth2 token, into a single standalone auth server that saves session in Mongo and creates active profiles, with token/session/code/id fields and with many standardized atribute fields in SQL server using Tedious.js. These passport tools are excellent, thank you.
My last challenge for this project is not going as well, username and password into an active directory repository, to look up and auth in the same way. I have been trying over and over again passport-ldap, passport-ldapauth (based on ldapauth-gfork, based on ldapjs), passport-windowsauth and passport-kerberos, and seem to be getting related credential errors (deep in code, adding console.logs to try and figure out what I am getting syntactically wrong).
Are there any other resources and documentation to accessing LDAP/AD in Node.js using any strategy of Passport? The DN versus ou syntax and where the account access user (have a service account specifically set up to access the AD) for the repository versus the account user you are looking up and the filters make it very difficult to find anything error related to figure out where I am going wrong. Do you match to sAMAccountName or uid? I keep consistently getting "unauthorized" errors.
Unlike the other 70 passport strategies, where the doc and examples are clear and just work, not so much for ad/ldap passport. Can anyone point me to a good test, doc or setup that works well specifically with Passport.js and Active Directory?
While this is an old question I thought, as the maintainer of passport-ldapauth, I should clarify LDAP authentication a little.
LDAP authentication is different from those strategies you've used before. Those OAuth strategies can really be configured only one way - provide the required options, and then it works. This part is the same with LDAP, but the actual values to the options differ from one server to the other. The questions you are asking, like do you match to sAMAccountName or uid, are really up to you and the LDAP server.
General things like what does a DN look like, what is search base, or what is the syntax of search filter have been defined extensively in RFCs. If one is not familiar with the basics it can be difficult to get the authentication to work. Often the AD/LDAP server maintainer input is needed to have proper settings, eg. what search base allows finding all required users but does not cause unnecessary load on the LDAP server.
LDAP authentication usually works in three steps:
Using a service account (in passport-ldapauth, bindDn and bindCredentials), bind against the LDAP server.
Once bound, perform the configured search substituting the placeholder with user provided username. This determines if the given username is found from the LDAP server.
Use the DN of the search result, together with user provided password, and bind against the LDAP server. This verifies the password.
If you wish to have users login using their SAMAccountName, your search filter could be eg. (sAMAccountName={{username}}). If you wish that the users use uid, the filter could be just (uid={{username}}). If you want to enable both, use (|(sAMAccountName={{username}})(uid={{username}})). The search filter syntax is specified in RFC 4515.
I was able to authenticate to AD via passport-ldapauth.
One key was knowing to use server opts which are different than in some LDAP examples online
searchBase: 'ou=Accounts,dc=mydomain,dc=com'
searchFilter: '(sAMAccountName={{username}})' // {{username}} comes from the html form.
You also need to know if you need ldaps and TLS or not. (I did not) I spent a good amount of time digging through ldapjs.org.
Microsoft have released an official library for this:
https://github.com/AzureAD/passport-azure-ad
Add to your project from npm directly:
npm install passport-azure-ad
Or Auth0's passport-azure-ad-oauth2 for OAuth2 flows.
I am not sure how flexible you are with your requirements, but I was researching the same subject and stumbled upon a specific solution from Microsoft that uses AD FS as an Oauth provider
https://msdn.microsoft.com/en-us/library/dn633593.aspx
A superficial reading shows that a web client contacts AD to get a JWT token, then this token is sent to your server, which then authenticates the token with the AD server.
The AD server needs to be configured to accept your server as a relying party that needs its identity service.
I am a consultant. The company that I am doing work for has given me limited access to a couple servers. I do not have permission to log on to the ldap server.
I am using the following to bind:
(sAMAccountName={{username}})
If I cannot physically log on to the ldap server am I not able to authenticate via ldap?
If they give me access to log on to the server, ldapauth works.
Gina
One of my requirements is to implement single sign-on for a set of sites. There is no need to support Open ID as usual nor become Open ID provider. However, I think about using Open ID internally. My questions are:
If my Open ID provider is limited to a trusted list of domains authentication experience will be transparent to users (except few redirects to the provider sub domain and back and bit different forms design)?
Since the provider is not public (a list of domains to check redirects against) there will be no new attack surface introduced?
If one of the sites has a desktop application should the application talk to the provider directly or via a facade of the site?
Found similar question which is useful but does not really answers mine.
1) Yes, the experience can be similar, but not seamless. For example, you might not be able to have username/password login box on the site.
2) The provider has to be accessible by the client (not just Relaying Party). So it depends on whether your clients are internal or internet.
3) It really depends on whether the application can do OpenID. Also, see (1), can the application handle opening up of the provider webpage?
Kerberos, NTLM, forms, claims based, use of active directory?
Going through the difficult process of analyzing which authentication method to use for a Sharepoint build-out, and I must be honest in saying that I'm confused as to which the best use-case would be. It's going to be used as an intranet and extranet, and am wondering what authentication methods other people are using and why they chose the authentication method they did.
Many thanks!
We use claims based kerberos.
Claims based because we started with Windows authentication, but want to leave the option for enabling forms based authentication open. (Forms based authentication is not available in classic mode)
Kerberos because it allows us to overcome the double-hop problem.
Setting up Kerberos brings some additional configuration requirements. Although it may seem intimidating at first, it is well documented: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en
Also claims based authentication has it's problems/limitations, but until now I didn't encounter something that made me change my mind about it.
In your case, if you want to make your SharePoint available as an extranet environment, you may want to go for claims based authentication. That way you can use Windows authentication for internal people and forms authentication for external people (customers/suppliers/...).
When making integrations NTLM is the preferred one, Kerberos is nice (and safer) but if the AD goes down your intranets and extranets wont be accessible.
So, Kerberos if you are paranoid, NTLM if you want high availability and good enough security.
Are there any open source centralized authorization services available? There are lots of solutions for centralizing the authentication information (eg: CAS and JOSSO), but what about the authorization information?
There are some really good authorization frameworks (eg: Spring Security (formerly Acegi) and Seam Security), but it seems that I have to composite these into individual tiers or services. In other words, I can't run them standalone very easily. With a SOA, it seems like it would be very valuable to centralize not just the authentication but the authorization information as well (ie: roles, permissions, rules, etc.).
Any suggestions?
Are you looking for something that supports XACML? If so, the closest to open source you can get is the OpenSSO project which has portions of what you seek.
The openly available Kerberos implementations provide Client Service Authorization as well as Client Authentication.
Read about Using Kerberos 5 on Red Hat Linux.
Hum, maybe you can use a SSO solution and create a service which returns all the authorization information (roles, permissions, rules, etc) and make each application use this service to get each authenticated user authorization information.