Currently our company uses a very simple login system involving salted MD5 hashes stored in a database and compared with passwords POSTED to a PHP page. We manage page view permission using PHPGACL. Now that our company has shifted from managing a couple dozen logins to a few hundred this system obviously not only presents a security threat but is also a maintenance hassle as we start to integrate more enterprise tools into our system and need users to have distinct logins for each tool.
From my understanding, OpenLDAP will allow us to replace this system with a single login that works across many platforms (google services, JIRA, etc) and a more secure password encryption mechanism. It would also still allow us to maintain the same page access controls that phpGACL offers.
Is this correct or do I have some fundamental misunderstanding of what LDAP is supposed to do? Are there any technologies other than OpenLDAP that would be necessary for migrating a system like the one we currently have? I've heard good things about LDAP but I'm still not very clear on what it actually does and does not do.
Many applications are able to use external (meaning external to the application) LDAP repositories for Authentication and some for Authorization. But, Not ALL applications will work with LDAP.
Google services typically requires some federation or synchronization to be used with LDAP.
You would need to verify other applications ability to utilize LDAP.
-jim
Related
I'm developing a system using Yii framework and mysql
and after finishing it i'm going to develop another one.
Those two systems should be shared with the same authentication module.
And maybe there are more systems coming up.
But I don't want to have two separate module for each project doing the authentication and authorization and I don't want to assign each user two passwords.
I'm searching for a mechanism to make the A&A process done with one external and shared system and let those two systems communicate with this system to get the rights for the current logged in user.
You need to implement SSO (Single Sign On) or to use some other method to overcome this.
Check here for a simple guide on how to implement SSO: http://merbist.com/2012/04/04/building-and-implementing-a-single-sign-on-solution/
Also check some enterprise implementations like http://www.onelogin.com/
Finally some open source implementations will probably help you like https://github.com/jasny/sso
I have 2 sites:
SITE A - an asp.net site
SITE B - a php site
We have all the user information in an asp.net site (which is actually a Kentico site).
Now, there is a business requirement that users should be able to log-in with the same credentials in Site B. Ideally, we would need that users who log-in Site A, and navigate to Site B, the authentication would be automatic.
Is there a way to achieve this form of authentication. Or is it not possible?
This is not an authentication problem, but an authorization one. Once you have authenticated your user, in whichever way you want, with whichever technology you want, you probably will grant them some sort of token that you will then use to grant authorization to the different resources in your sites.
In your case you have two different technologies, which only means that you won't be able to use the out of the box asp.net or php session management, but all you need to do is have a common place to check that the session tokens are valid, they belong to a legitimate user and that user has permissions to access this resource.
If the above is trivial, sorry, maybe your question is more oriented to the sites being in two different domains, and therefore not being able to use a domain cookie to store the session information. is that the case?
The canonical solution to this is to use a protocol like OpenID. OpenID allows a website to ask a user to authenticate themselves using a different site, and then honour those credentials; using a protocol called "attribute Exchange", the authentication provider can provide additional data about the user.
OpenID is how StackExchange manages to log you in with your Google account (or whatever you're using), and how sites in the SO network recognize your identity without you logging in everywhere.
The benefit for OpenID is that it's a widely used protocol, so it's likely to be highly secure and well-tested; you don't risk weaving your own solution and accidentally exposing your users to security risks. It's well-documented, and widely supported.
There's an OpenID framework for .Net which allows you to create your own OpenID provider; it appears Kentico supports OpenID as an authentication mechanism. There are several OpenID libraries for PHP (Google is your friend here).
Exactly how you implement this depends on how your Kentico authentication works right now, but in principle it should be fairly easy to glue the Kentico user database to an OpenID provider you write; getting Kentico to use that for authentication appears to be a configuration setting. You'd have to re-write the PHP site to use OpenID; again, not clear how that currently works, but I can't imagine it would be harder than any other solution you might try.
I had a similar issue on a .net platform where I didn't have the option to put them on one subdomain. In that case you could pass the username and a token (that signified the user was already authenticated by site B) and perhaps the encrypted password to re-authenticate against an external DB, then redirect them to the site. In my case I needed to do this as I was redirecting to the corresponding site CMS for site admins.
I have written an API for my latest project. Written entirely in PHP, it currently supports web and mobile applications. We would like to expand that to desktop applications as well, but I'm not exactly sure how to enable to user to login through the desktop application, while still protecting the username and password from said application.
There are many brilliant developers on Stackoverflow, so shoot me some brilliant answers!
The application will be developed by 3rd parties, so I want to ensure they aren't able to store usernames and passwords
If the application has to send usernames and passwords, then it has to be able to have access to them, so don't use them inside the application at all.
Use OAuth. This is the solution used by quite a lot of large organisations, including Twitter.
There are many possibilities. What comes to mind:
Issue a Certificate signed by your CA and verify later, eg via the OpenSSL lib or Apache.
Use Public key encryption, eg via GnuPG lib, and grant access only to known pub keys.
Use any kind of Token based authentication or any other two factor authentication..
Just give them another set of API credentials (Secret Key, API Key)
its a desktop application, it has full access to the users keyboard and memory. if the application should have a login form where end users type in their usernames and passwords, the application has this data by definition.
the only solution would be to distribute the login-application yourself which does some sort of toked based authentication and provide the 3rd party applications a login token via your api.
oauth and other singe-sign-on systems on the web usually use an iframe or popup which comes from the system-to-login-to itself. no 3rd party website or application should be allowed to provide this input fields.
Is there any way that I can integrate the UserCake user management system with MediaWiki? I want to link the accounts in each system so users can log into both with the same username and password.
There is no existing system to do this. You can create an extension for MediaWiki to do this without too much trouble. Basing it off an existing extension is probably a good starting point. By looking at AuthJoomla, AuthBugzilla and AuthSymfony you should get a good idea of how MediaWiki's authentication extension API operates. It's really just a matter of creating the class, getting it to call the relevant UC functions and then loading it as an extension into MW.
Having said that, UserCake seems unmaintained. It may be worth taking this opportunity to migrate your users to another authentication system. If you are using credentials between several applications you might want to look at something like LDAP.
I know that this is a really old question, but UserSpice is the fully PDO/OOP spiritual successor to UserCake and would probably be better equipped to handle this. It would take some modification, but it could be done.
May I recommend that you use other ways to secure you applications. Take a look at Windows Azure ACS that gives you security federation to Facebook, Google, Yahoo and more.
This allows you to focus on your application and not security protocols.
Azure ACS supports many different of protocols and works great with PHP as well as .Net based applications.
I did a quick search and found the http://www.mediawiki.org/wiki/Extension:OpenID that can use Azure ACS. (Access Control Services)
There are other alternatives to ACS such as Ping Identity and OpenSSO; But ACS is a cheap alternative to Ping.
I'm managing a set of web apps, almost exclusively written in PHP, and would like to find an authentication platform to build a role-based authorization system on top of. Also, I'd like the authentication system to be extensible to use for, for example, system services (SSH, etc.)
Here are some of the main characteristics I'm looking for, in order of importance:
Easy PHP implementation (storing/reading easily roles, etc.).
Redundant, if possible. If an auth system goes down everyone is not locked out.
Has clients for Windows and Mac.
Easy web-based administration (adding/removing users/roles, changing passwords). If not, I can build an administration system without too much effort.
One-time log on.
I'd also like, when an auth token is issued, to store the user's IP address and use that to authorize the user for some non web-based applications. For that reason, I'd like a desktop client to issue the token and revoke tokens when, for example, the user becomes idle at their workstation.
I'm thinking Kerberos might be a solution, but what are other options?
If I were doing this, which I actually have at several points in the past, I would use a combination of Kerberos and LDAP. Kerberos handles authentication and provides users with tokens. LDAP provides authorization; information about group membership, user contact information, etc.
Kerberos is very, very well-tested and widely deployed. To protect a web application with Kerberos, use Apache's mod_krb5 or a solution like Stanford WebAuth. The user authenticates once to Kerberos and then their browser will use the ticket via SPNEGO to automagically log them in to the web application. If you have a Windows Active Directory Domain, then your users already have Kerberos tickets you can use from their computer login session!
Kerberos is also supported in many other network server programs, such as OpenSSH, various IPSEC VPN tools, email (both SMTP and IMAP), XMPP (Jabber) chat, etc etc.
A Kerberos infrastructure can be as redundant as you like, and organized however you like. Realms can have many servers providing authentication, and can trust eachother in arbitrary ways.
It's not just a solution, it's the solution for single signon.
What you're looking for is (essentially) a Lightweight Directory Access Protocol (LDAP) server/client setup. PHP has a built in library, it's easily redundant, has clients for windows/mac/linux, front ends are available (though I can't recommend any good ones at the moment) and it'll provide authentication to any set of applications you want.
While there are some additional pieces you'll need to put in place to achieve exactly what you want, LDAP sounds like the framework you should start with.