LDAP Support Available?
orware opened this issue · comments
Good afternoon!
I just came across your project and am probably going to try experimenting with it when I have a chance but I wanted to ask if it already has support for the authentication to occur against an LDAP server or can it only authenticate against its internal database?
Thank you!
I got to try it out just now and overall the getting started process wasn't too bad (the node/gulp requirement I know is becoming more common in PHP projects so that wasn't too bad, but it's always a slight slowdown to the overall process). After I had node installed and gulp installed those commands ran fine.
Next I setup the .env file with some of the database info but then wondered if there was an installer. However since I saw the Laravel usage I figured I could utilize the php artisan migrate option, which worked fine to get the tables installed.
Since I'm running XAMPP locally, I was trying to run the site out of a subfolder and that wasn't looking correct (browsing to http://localhost/php_cas_server/public/cas/login wasn't allowing the CSS/JS/Image resources to load properly since they were expecting to be served out of the site root). I wasn't sure how to fix that exactly, but just so I could move forward I instead tried the php artisan serve command instead which makes things run out of the site root as the code was expecting itself to. That allowed me to see the login page properly and try registering an account in.
Next, I wasn't sure how to get to the admin page (I tried /admin which didn't work), then I thought maybe if I switch my user to be an admin one it'll show up after I login and that seemed to be how things worked and I was able to get into the admin area after that.
There doesn't seem to be any sort of LDAP support yet that I can see (you might still have some ideas you could provide if that is an option that's available) so it might be something I could help test/enable via the plugin option you mention in the README.
The next stage for me is to try out adding a service and attempting a test login and get a feel for how that works. Interestingly, the WSO2 product we've been using here on campus seems to want its services to be more of an exact URL, whereas your tool seems to be more flexible in allowing certain domains in (I'm not sure if that's better or worse...it certainly makes some things slightly easier since on my end I don't have to worry about specifying all of the exact URLs that might be making a login request).
At the moment I'm not sure if the CAS Gateway feature and Single Logout options are supported nor do I know if extra attributes would be supported as well (though this might be something I figure out if I start working on an LDAP plugin).
An example of a CAS response that has more attributes coming from an LDAP source (Active Directory):
Example Student Login Response:
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
<cas:authenticationSuccess>
<cas:user>jdoe1</cas:user>
<cas:attributes>
<cas:mail>jdoe1@students.example.edu</cas:mail>
<cas:sn>Doe</cas:sn>
<cas:title>Student</cas:title>
<cas:cn>jdoe1</cas:cn>
<cas:role>Internal/everyone</cas:role>
<cas:givenName>John</cas:givenName>
<cas:displayName>John Doe</cas:displayName>
</cas:attributes>
</cas:authenticationSuccess>
</cas:serviceResponse>
@orware Hi, I'm sorry to tell you that this project's plugin mechanism doesn't support custom data source, it's impossible to load users from LDAP for now.
CAS Gateway should work as any other CAS servers, you can connect it with any CAS client which follows standard CAS protocol V1/V2/V3. You need to use V3 in your client to get extra attributes.
Single Logout options are not supported yet, I don't think I'm going to implement this.
Thanks for the update, I'll hopefully take a closer look and see how the custom data options work in more detail and see if I can figure out a way to integrate LDAP in there and share that with you if I'm successful.
The Single Logout option would be nice I think to at least consider (I didn't initially think it would be useful, but now that I'm thinking about it more...it seems like it would be pretty useful because I think otherwise if a student was sitting on a public PC and they logged into two CAS-enabled sites, but only explicitly logged out of one of them, then a second user comes to the machine and goes to the second site I think it would still be logged in as the first user which would probably be a situation to try and avoid, particularly when there's sensitive data involved).
Since I'm kind of curious, what led you to build this project and how are you using your software at the moment? (I haven't seen very many CAS server implementations in PHP, but out of the two I have seen this one was at least quite a bit easier to get setup, though it's still a relatively new project).
@orware The original aim of this project is to help startups who build their business using PHP stack, I hope they can build and extend an SSO server easily. In this case, most users are using their own computer, so it's unnecessary to implement single logout.
In the other hand, the specification says that SSO server should send a POST request to all service urls when single logout, the body of request is
<samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="[RANDOM ID]" Version="2.0" IssueInstant="[CURRENT DATE/TIME]">
<saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
@NOT_USED@
</saml:NameID>
<samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex>
</samlp:LogoutRequest>
but I can't figure out what the [SESSION IDENTIFIER] is (for php sites), seems like something out of the protocol which makes it hard to implement.
I will appreciate if you can help me to understand what is that, maybe I can implement it.
Thanks @leo108...at the moment I'm not really sure either. I was reading through the CAS Protocol in more detail and saw that same section with the mention about the SAML response and was kind of wondering why they switched to SAML for that.
At the moment I'm starting work on my own CAS Server implementation as well (I really think yours is great, but the use case for colleges tends to be a bit different and in ours the need to tie into an LDAP store is pretty critical, the only minor negative I had with yours is that the Laravel framework ends up adding a lot of magic to the process so I'm hoping to keep things as simple as I can here on my end by not using a framework...I'm hoping I can have something usable with a tie-in back to LDAP sometime today...though that might be too optimistic :-).
The main part of the protocol I don't really understand well yet is the proxy feature (maybe because I don't think we've gotten far enough in our use of CAS here on campus to have a good example available yet so I can visualize what it's useful for). If you have any more details you can share of your understanding of that feature that would be very helpful :-).
@orware https://apereo.github.io/cas/4.2.x/protocol/CAS-Protocol.html#proxy-web-flow-diagram here is a diagram that may help you to understand the proxy