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.
Related
In a legacy Windows Forms application, users are now identified by an LDAP query. In essence, they scan their badge (barcode) and the application runs an LDAP query to get user attributes.
I know, from a security perspective, this is bad, but usability is more important than security in this case (we're talking about machine operators and they just need to sign-in / sign-off).
Now, we would like to move to a web-based architecture and the simplest thing would be to run the LDAP queries from the back-end to achieve the same.
However, I was wondering if we could switch to a more secure solution using ADFS and RFID/NFC badges, but I can't find any existing implementation. (I'm not looking for 2FA).
So, I'm trying SO, knowing this question can result in opinionated answers: if anyone has experience with a similar use-case, please stand up.
ADFS doesn't do this OOTB.
You could write a custom authentication feature or use the MFA server.
I see you don't want MFA but if you look at the screenshot, it does more than MFA.
I don't want to store passwords on my server and I don't want to force my end users to create yet another account, that's why I'd like to use single sign-on. I'm looking for a widely accepted solution for the authentication, I think about OpenID and OpenID Connect, the former seems to be more widespread but obsoleted and no longer used by Google, the latter seems to be faster (thanks to JSON?), safer but less widely adopted.
I'd like to share some documents on Internet. I want to control who can view them. I have looked at OwnCloud but it seems to be too much for my needs.
My website contains some photos and some articles, I want to show some of them to everybody, I want to show some of them only to my family and my best friends but not my colleagues, I want to show some of them to all logged users but not everybody and finally, I want to show some of them to … nobody.
I use Apache HTTP Server, I want to be able to manage file access rights for my end users with their own means of authentication. I have looked at mod_auth_oid and mod_auth_oid_file, it handles the authentication with OpenID 2.0, it allows to define a mapping between OpenID and local user ids. Does it mean that I still have to store a password for each local user anywhere on my server?
A graceful server restart is required in order to load new mapping definitions
It's a bit annoying as I don't want to restart the server each time I edit the mapping. It's unclear to me whether it is still true when using mod_auth_oid_ldap. I really need an open source software that I can install on my server and adapt to my needs. I plan to use openid-selector with the Apache modules I mentioned earlier and some JavaScript code to handle gracefully the display of the forbidden content. Am I missing a more obvious solution? I'm not a big fan of Facebook but is this bridge working?
I've gotten pretty spoiled by the mature frameworks available in Python (Django/Flask), so as I'm starting to learn Go, I have to wonder if there are any similar frameworks already in existence in Go to django.contrib.auth or Flask-Login?
The main use case is to handle simple user authentication and be able to extend it to accommodate some permissions-based routing within the app.
As far as I know, there are not. The closest out-of-the-box authentication you can probably get is via Google AppEngine, where the user's Google account can be retrieved and certain paths can be scoped for app administrators only.
In a standard Go web server, you will generally need to roll your own auth, but it's not as difficult as it sounds. Many frameworks isolate you from decisions which are actually quite important; in typical Go fashion, you'll need to make these decisions based on the needs of your app, and then pick the existing libraries that are right for you.
Login page
Wherever you need your users to log in, you will probably use an HTML form. These will typically be rendered using the html/template package. To retrieve the values when the form is submitted, use request.FormValue.
Database
There are a number of ways to store user information; on the filesystem with os or in a SQL database using database/sql. There are mature drivers for some NoSQL databases as well, including MongoDB and Redis.
Passwords
To compute and compare hashes to passwords, you'll want to use a preexisting mechanism so that you don't have to reinvent it yourself. For this, the go.crypto subrepository provides a bcrypt package.
Sessions
If you want to store session data, you can use a solution like gorilla/sessions. Based on your security needs, you can store the session data directly in a (optionally secured) cookie or you can store it in a backend an only store a session ID in the cookie.
From the READ.me
Allows your Martini application to support user login via an OAuth 2.0 backend.
https://github.com/martini-contrib/oauth2
We're currently evaluating SAP Business Objects XI 3 for a front end reporting solution, but I'm not happy that we will need to create a new set of logins that will be managed independently from our existing website. We have an authentication API that our various applications all hook in to, so we effectively get single sign on, and single account management.
Is there a way to write a custom authentication plugin for SAP BOE 3? I've googled for information and have come up empty handed. Links to documents would be handy also.
The solution that we use for this problem is to have a seperate password management page built into the HR space that will change all the user's passwords to the same thing. So there is one input for username and pass that changes the global password for a user and then it runs through and changes all the different SAP ones that are needed.
Not really the answer you are looking for, but it is somewhat of a solution.
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.