CAS protocol - refresh token? - php

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.

Related

SSO across multiple websites (multiple databases)

slightly losing my mind here and I would really like some help to get me pointed in the right direction.
I'm using a shared Linux server on GoDaddy where I have two PHP websites with separate user logins authenticating with two separate MySQL databases. What I'd like is for a user to log into Site 1 and then be automatically logged into Site 2. And when they logout out of either site, they should be logged out of both sites.
I currently have SimpleSAMLphp installed and I'd really appreciate some guidance on how to setup the IdP and SPs. Am I right in thinking that the Site 1 and Site 2 are the SP's?
Any guidance would be greatly appreciated, this is my first ever SSO setup and I'm just a little lost.
To implement single sign on you need somthing common in both website to authenticate. Cookies won't help as there are two different site and it is not good to expose your cookies to a another website.
In general, SSO is implemented using a central serevr basically which handles the authentication data.
Basic steps are as follows:
For login, user is redirected to the common server and credentials get verified.
Central server sets the cookie for the login.
When your other website needs a login it checks the central server again using redirection.
Then, central server check the cookies and authenticates or redirect to login if not aythenticated before.
So, you can configure a central authentication server which check authentication and provide the appropriate response and both websites handle it accordingly.
But, Central server needs a common user database which in your case you clearly lack. So you can declare one of the websites as central or principle resource and expose APIs for other website which will expose its user base to verify the details.
Let one website handle the login process. If other needs authentication to be done it will redirect user to the main website and then handle the return response.
There is a lot to cover in theory but hope it would help.
Useful links:
Building and implementing a Single Sign-On solution
Basics of Single Sign on (SSO)

Securing application access to pre authorized individuals only

I am building a PHP application and would like to lock the backend (even login page) to only be accessible to preauthorized people - even further be able to link activities to the authorized individuals.
I am aware that such locking may be done using SSL or a certificate of sort but not sure what it is exactly or how to achieve it. I have seen different companies implement it in ways as mentioned below
At one company, A user fills in a form with details and the company issues a certificate that the user installs on the browser in order to access the backend
Another company, A user is given an exe to run each time they want to access the backend.
My PHP application is running on windows server 2016 and I would like to know how to achieve both or either of the above. A resource or specific would be appreciated.
I am not sure if this question is right here or another Stack Exchange
Network, kindly forgive my ignorance.
First of all:
Do not cross post on different networks.
Secondly, the way to do this is to supply client certificates from another web app that are accepted by the app you're developing. Key words for research are: TLS, client certificates, certificate based authentication.

Single Sign on Authentication with CAS

I am trying to implement single sign-on authentication between two of my applications one in PHP and the other in .NET. The PHP site currently makes a Web Service call to a .NET Web method to authenticate the user. Both the .NET site and the PHP site use the same database. I was inclined to think I could implement a single sign on mechanism where if the user logs in to the php site he is automatically authenticated to the .net site as well. CAS authentication seems to be somewhat relevant to my case. But I am not sure where it exactly fits between my applications. So let me break it down into distinct steps please let me know if I am right?
User visits www.myphpsite.com/login
He supplies the username and password and clicks on the login button.
A web service call is then made to the .NET web method hosted in the same server as my .NET application www.myDotNetApp.com
The Web service uses the database to authenticate the user.
Somewhere here CAS has to fit in and has to ensure that I am authenticated for both www..com and www.myDotNetApp.com. In addition to doing this it has to set some session variables for the www..com site for the user to be able to view the different pages in the site.
Then the Web method has to redirect the user to the homepage in the www.myphpsite.com.
Now if the user clicks the link to www.myDotNetApp.com from www.myphpsite.com he must be taken to his profile page in www.myDotNetApp.com because he is already authenticated.
Now, is it possible to achieve this? If so, how?
What you propose is possible but I would suggest doing a little reading about how CAS works, the CAS Protocol is a good resource.
What CAS provides is an authentication provider trusted by each of your websites. It is an additional hosted website / service along side your other websites wanting to use CAS to provide authentication.
Based on the information you provided in your example, here is how it would mostly likely play out:
User visits the PHP website www.myphpsite.com/login, recognizing the user is not yet authenticated the PHP website redirects the user to your CAS website.
The CAS website also does not recognize the user as authenticated and so presents the user with a login screen. The user enters their credentials which CAS verifies against the database and then redirects the user back to the PHP website.
The PHP website receives a service-ticket from CAS via URL parameter which it verifies with CAS making a back-end web-service call. Having received a confirmation from CAS that the service ticket was valid PHP then logs the user in using its built-in authentication procedure (i.e. instead of validating against the database the PHP website now validates with CAS to assert that a user is authentic).
At this point if the user attempts to access the .NET website www.myDotNetApp.com it would not be able to recognize the user as authenticated using its built-in authentication procedure and so it would redirect the user to the CAS website.
However, the CAS website would already recognize the user as authenticated. Instead of prompting the user to login, CAS would automatically redirect the user back to the .NET website providing a service-ticket as a URL parameter. The .NET website would then make a back-end web-service call to CAS verifying the service-ticket and log the user in using its built-in authentication procedure.
In summary, CAS provides a single place for users to authenticate. Other websites can then direct needs for authentication to CAS where CAS either asks the user to login or recognizes the user as already logged and notifies the website.
Think of CAS as being the HUB and your apps as being spokes in the hub & spoke model. A lot is based on implementation, but here's the general process.
When a users hits a protected area of your php app they will be redirected to CAS. They will authenticate against CAS which has been setup against your database. After successful authentication, they are routed back to your application with a token that gets verified and they are signed in. If the app is implemented correctly, then they end up back on the same page they were attempting to navigate to.
When they hit a link that sends them to your .net app, they will go over like normal. If the page requires authentication, then they are routed to CAS which already knows them and passes them back to the app with a token that gets verified and then get in, and most likely never realized they hit the CAS application.
Just in case it is pertinent, let's assume that the PHP app needs to call the .net app as the user, not just linking to a page, but needs to get .net content as the user him or herself... CAS also supports proxying, so the php application can impersonate the user and call .net directly.
Check out the CAS architecture and the protocol for more details.

How to uniquely identify a client in a web (PHP) application

We've been developing a web application (PHP, using the Yii PHP framework) that is going to be used for data entry. The clients will be users from both the LAN and WAN (many of the remote clients will be behind a proxy, reaching our network using one IP address with NAT). What we basically want is to guarantee the validity of data in the way that no malicious user alters it.
Is there a way to programmatically identify each client in a unique way, so that I can guarantee (at least at some good percent) that no malicious remote user will connect? We were thinking of gathering the MAC addresses of all remote users and using a (non-web) client that generates a hash string that the user will input in the web application and then proceed if this authentication scheme passes. As I said, using other non-web applications for the remote client is an option.
Is such a solution as the one I describe above viable? Should we see other solutions, like maybe a VPN?
A VPN is a typical solution to the problem of locking out everyone except those you've explicitly given access --- basically you're rejecting all connections to the site that aren't authenticated in your local network or vpn. That way you dont have to write any funky logic for your actual web application.
I think this is an ideal solution because it allows the application to be maintainable in the future when other developers step in... furthermore it will require less of your developers and will ultimately keep costs down.
Normal user authentication is generally OK, but if you have higher security needs you can provide clients X.509 certificates to install in their browser. VPN is of course an option but you just move authentication problem from website to network vpn.
What you are looking for are the SSH-Key pairs:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys
There are much more ressources on this, the theory in brief:
Each client creates a pair of unique keys, a private and public one. The public goes onto your server, the private stays with him. Then the client uses the key to authenticate. The server calculates a valid public key from it and checks if you have such a key in your system. If a pair is found - authentication was successful. (I never used this so far for Web authentification)
Additionally you could use OTP (One Time Password) technology. Since it is normally bound on per-account basis it will be very secure:
https://github.com/lelag/otphp

Authentication for SaaS

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.

Categories