I have a webpage that I only want a specific group to log into.
I work at a college and we use Active Directory accounts and only a certain group can access this php page (on apache server).
I know I can restrict access with some PHP code, but I want to accomplish seamless login.
Everyone uses IE7 at work (which are configured to pass the proper credentials), and are required to log into the computer (which logs them into the domain controller).
When the user goes to http://intranet, they will automatically be logged in, since they logged into their computer earlier.
If a user goes to http://intranet.domain.com, it will prompt them for their credentials.
I know I need to use kerberos for authentication and LDAP for authorization.
Has anyone had success at seamless authentication?
There are commercial products that offer this as Apache modules, see the links at the end of the Wikipedia article on SPNEGO (eg. Guide to SPNEGO with Apache). I know also of some php modules like php_krb5: php_krb5 beta / Negotiate auth with GSSAPI for PHP, or Apache modules like mod_auth_kerb. I never used them myself though.
As for going the whole 9 yards and implementing Negotiate auth in PHP, I did implement in my life RFC 2617 in PHP for Digest HTTP auth and I did implement Windows SSPI authentication modules, but I never tried to implement RFC 4559 in PHP. While the HTTP auth part is fairly trivial, the opaque GSS-API part is daunting, even provided you have a good GSS-API library at your disposal for RFC 2743.
This is because you need to add intranet.domain.local to the Local Intranet zone in IE. Check this article for details: http://www.sysadminlab.net/other/local-intranet-zone-in-ie8-exaplained-for-sysadmins
Related
I am learning about SAML and already read many articles and forums but I still having confusion about setup IdP.
I am using "https://simplesamlphp.org/"
For example, I have 3 websites "example.com", "one.example.com", "two.example.com";
All are on three different server.
Now, I want to setup single sign on login using SAML then on which server I need to setup IdP.
As "example.com" is main domain which has all the information about user.
As I learn, when I login to "example.com" then it sends request to IdP.
But I don't get any idea where I have to set IdP and what Idp contains?.
Its on same server where "example.com" hosted OR its different server and what logic I have to write on that server?
It's simple login function OR I need to setup "simplesaml" for this and set login logic to there.
After setting up IdP, what I need to do on other server "one.example.com", "two.example.com"?
Do I need to install again "simplesaml" to both server and set SP and IdP?
In sort, which server has IdP and SP? And on which server I need to install "simplesaml"?
Thanks in advance
simpleSAMLphp is the IDP.
You don't need to write any code, just setup the config.
You will also have 3 SP = the three websites.
They can all be on the same server or you can have one server for the IDP and one server each for the websites. It doesn't actually matter.
The simpleSAMLphp web site shows you the changes you need to make to each of the SP in order to communicate with the IDP.
Identity provider is the one who supplies info about users. You'd create one, let's call it idp.example.com.
You'd install simpleSAML there and configure it so it can read info about your users, be it in MySQL, LDAP etc. (this is the tricky part with IdP setup).
Now, your websites would be service providers and if user isn't authenticated, they'd redirect the user to idp.example.com, user logs in, idp.example.com returns the user to service provider with the XML document containing assertions.
That means your SP needs to be able to consume the SAMLResponse which IdP sends to your site.
You can consume this with simpleSAML, which you'd configure in SP mode now.
Bear in mind that SSP (simplesamlphp) isn't the only option in PHP to deal with SAML. There's also Lightsaml - a proper library. SimpleSAML isn't just a library, it's a complete solution and quite honestly - a super SUPER terrible one at that, it's the epitome of crap code one can type out and make a system that actually works (much like wordpress).
TL;DR:
create an IdP -> idp.example.com -> configure or create the module that authenticates users against your user source (LDAP, ActiveDirectory, relational database etc.)
configure your 3 websites to authenticate using idp.example.com
configure your 3 websites to be able to consume responses from idp.example.com
It's all doable with simplesamlphp. If you want to take it further and implement or play with SAML on your own - you can use the library I linked. It'll take way, way, way longer to do it via Lightsaml library though since you have to take care of single logout and single sign-on, encryption, digital signatures, endpoints, metadata etc.
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.
We have an app hosted on our domain. All users are required to first log in through a POST form. Once login has happened, then form redirects to dashboard page on our site automatically.
Is it possible to allow some clients to host their own login forms (on their site), that POSTS to our app? Is cross-domain posting considered bad practise in any way? Are there any pitfalls to be aware of? And lastly, how is SSL taken care of given that our site always runs on HTTPS, but client sites may not? Can this be circumvented with an iframe?
What you are trying to reinvent is called openid.
What you need to do is provide a openid service, and then users can make there own login forms that connect to your open id server.
I have a great example of such a site: http://www.stackoverflow.com that uses google and others as openid service to log in, making there own login form.
What you're trying to do is generally referred to as Single Sign-On (SSO). This can be implemented using a variety of technologies.
The general idea is to separate the Service Provider (SP) (also sometimes called Resource Provider), which is what provides the actual service the user is going to use, from the Identity Provider (IdP), which is where the user's identity is verified.
The simplePHP library provides implementations for both IdP and SP authenticating layer using a number of SSO standards: SAML, Shibboleth (also SAML-based), OpenID, ...
Note that if you're using a standard, the IdP shouldn't need to be implemented using the same implementation as the one you've chosen for your service. It could be possible to have an IdP implemented in Java using the Shibboleth libraries and use it in conjunction with an SP that uses simplePHP, for example.
Which of these techniques you use will depend on the kind of information your require after authentication, for example if extra attributes are required, and how trust is managed between the IdPs and the SPs.
Typically, a simple OpenID system will be rather straightforward to integrate, from an SP point of view, but it will be quite limited in what it can assert about the user. In contrast, Shibboleth has a number of options to specify which SP can see which user attributes and what IdPs are meant to release or not, but it requires a more substantial infrastructure: this is typically done in a federation, where all the parties exchange a set of metadata configuration that comprises X.509 certificates they use to trust each others' assertions.
Since the authentication will happen outside your administrative boundaries, you can't really control how the users will have authenticated (unless this is part of a more formal agreement, such as in a Shibboleth federation). The OpenID provider could potentially let users authenticate over plain HTTP even if your service requires HTTPS. (This being said, most serious OpenID providers do it securely, and it's up to the user to pick one their trust anyway.)
Never embed the IdP page in your service: make the user go to a their IdP page instead. For an authentication system to be secure (as far as the user is concerned), it is essential that the user be able to see what they're typing their passwords in. By using an iframe, you would effectively hide the real site behind (and logos are easy to grab/forge). (The StackExchange OpenID provider has some problems in that respect.)
What would be recommended as an authentication solution for a Software-as-a-service product?
Specifically, my product would have clients that would typically have low information technology skills, potentially not even having an IT department within their organization. I would still like to have my application authenticate against their internal directory service (eDirectory, Active Directory, etc.). I don't want them, however, to have to open/forward ports (for instance, opening up port 636 so I can do LDAPS binds directly to their directory service).
One idea I had was to have an application installed on a server within their organization's network that would backconnect to my service. This would be a persistant socket. When I need to authenticate a user, I send the credentials via the socket (encrypted) - the application then performs a bind/whatever to authenticate against the directory service and replies with OK/FAIL.
What would you suggest? My goal here is to essentially have the client install an application within their network, with very little configuration or intervention.
This vendor, Stormpath, offers a service providing exactly what you are asking for: user authentication, user account management, with hookups to your customers’ on-premise directories (if need be, as is your case).
I think in your case, it'd be necessary to drop an agent on to their network which performs the authentication locally, then creates a signed token which "proves" to your SaaS app that it has done so; this can be passed on by the browser in a query string or form post (for example).
The agent might be an IIS-installable web app which can just authenticate the user and then direct them on to your servers in the cloud. This should not be a major hassle to install, but will create tech support issues. In particular, you need to get this component right first time, as users are not going to update it on a regular basis.
Making it work securely may be interesting.
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.