I am somewhat familiar with how to set up seamless authentication in PHP/ASP.net applications with IIS in a corporate network, but I have a question that so far I have struggled to find an answer to.
With anonymous auth disabled, and windows auth enabled, i.e. seamless authentication is set up, will a PHP/ASP.net script with functionality for adding/modifying users in Active Directory (into the same "container") simply just work for someone with the correct admin privileges, i.e. in php use of just ldap_bind($conn);, or must I force the user to supply login credentials to use in the ldap_bind() function?
Please understand that I have limited knowledge and understanding of AD.
Generally, an LDAP request is transmitted on a connection where that connection has a particularly authorization state and the LDAP client examines the response from the server for indications of success or failure. The authorization state of the connection is changed by a successful bind request.
Successful requests are therefore dependent on the authorization state of the connection. Properly secured LDAP servers should require applications to bind (to change the authorization state of the connection) in order for certain requests (such as add and modify, search andcompare`) to be successful.
Related
I am working with an existing legacy php authentication solution which works the following way:
Users put in their credentials
The code checks LDAP for authentication
If LDAP authentication is successful, the username is passed to a DB query to retrieve permissions
If LDAP authentication is not successful, the SQL DB is checked for authentication with the same credentials
If SQL Authentication is successful, the permissions are retrieved
If SQL Authentication is not successful, inform the user.
This is because many of our users are employees, and many are customers.
We now have a requirement from a secondary web provider to provide authentication via SAML. The request is to turn our existing auth method into a SAML Auth source. I've been experimenting with making a custom module in SimpleSAMLPhp but I'm not having any luck. The documentation for configuring an external auth source like this is lacking, and my existing code essentially inputs POST variables as arguments, which I haven't been able to shoehorn together. My difficulty in getting this to work is making me nervous about the overall security of the system if I did get it working.
What is a better solution to this problem?
From your question i have an impression that you are not very familiar with SAML protocol.
All i can do now is to give you some advices to get started.
First: Learn about protocol. Try to understand the SSO flow and differentiate which components in your company acts as "Service Provider" and "Identity Provider"
Second: Understand the scope of integration.Try to answer following questions:
- It's the application working in internal or external network ?
- Who have the access?
- Is there SAML authentication is already done for other applications in your company ?
- Is LDAP server is already controlled by Identity Provider, or you have to implement new one?
Once you get more familiar you can start thinking about development. There's many existing solutions and libraries available so once you get the concept of how protocol works it will be much easier to continue.
I will be happy to help you in your journey. This task will take you a lot of effort so be prepared.
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 went over the CAS server documentation over and over and am quite aware of data flow between client, server and app.
However, I am particularly interested in what happens in the following scenario:
User arrives at application, inputs the credentials and get authorized by CAS server
PHP receives the answer, creates the PHPSESSID
At some point in time, administrator removes that user from registry (be it DBMS, LDAP or whatever)
User sends request for protected resource - receives the resource
So, as you might see, security is my main issue here. How and when does the session/access token get verified/refreshed?
This question is about CAS and BeSimpleSsoAuthBundle but I believe it applies to other similar-purpose protocols.
This is what I have tried:
Installed/configured CAS on separate box
Installed/configured applicaation on another box
Used application to authenticate via CAS - success
User tries to access protected resource - success
Brought down Tomcat server that runs CAS
Tried to access protected resource in application - success (?!)
If I have missed something I'll be more than happy to update my question :)
Disclaimer: I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
It's the general design of CAS: you have clients and a server, which provides some advantages, but one of the main concerns is the fact that after being authenticated in your application, you may not communicate with the CAS server again.
In real life, except if you use remember-me, it's not generally a problem. After a few hours (at worst), the SSO / web sessions end and the removed user can no longer log in.
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.