summaryrefslogtreecommitdiffstats
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md26
1 files changed, 16 insertions, 10 deletions
diff --git a/README.md b/README.md
index 7d4db7d..05d9554 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,8 @@
-Simple Single Sign-On for PHP (Ajax compatible)
+Single Sign-On for PHP (Ajax compatible)
---
-Associated websites often share user information, so a visitor only has to register once and can use that username and password for all sites. A good example for this is Google. You can use you google account for GMail, Blogger, iGoogle, google code, etc. This is nice, but it would be even nicer if logging in for GMail would mean I’m also logged in for the other websites. For that you need to implement [single sign-on](http://en.wikipedia.org/wiki/Single_sign-on) (SSO).
+Jasny\SSO is a relatively simply and strait forward solution for an single sign on (SSO) implementation. With SSO,
+logging into a single website will authenticate you for all affiliate sites.
There are many single sign-on applications and protocols. Most of these are fairly complex. Applications often come with full user management solutions. This makes them difficult to integrate. Most solutions also don’t work well with AJAX, because redirection is used to let the visitor log in at the SSO server.
@@ -56,24 +57,29 @@ The client logs in, sending the username and password to the broker. The broker
[![SSO Binck](http://blog.jasny.net/wp-content/uploads/sso-diagram_binck-300x238.png "sso-diagram_binck")](http://blog.jasny.net/wp-content/uploads/sso-diagram_binck.png)
-You visit another broker. It also checks for a token cookie. Since each broker is on their own domain, they have different cookies, so no token cookie will be found. The broker will redirect to the server attach to the user session.
+#### Broker
-The server attaches a session key generated for this broker, which differs from the one for the first broker. It attaches it to the user session. This is the same session the first broker used. The server will redirect back to the original URL.
+When creating a Jasny\SSO\Broker instance, you need to pass the server url, broker id and broker secret. The broker id
+and secret needs to be registered at the server (so fetched when using `getBrokerInfo($brokerId)`).
-The client requests the index page at the broker. The broker will request user information from the server. Since the visitor is already logged in, the server returns this information. The index page is shown to the visitor.
+Next you need to call `attach()`. This will generate a token an redirect the client to the server to attach the token
+to the client's session. If the client is already attached, the function will simply return.
-## Using AJAX / Javascript
+When the session is attached you can do actions as login/logout or get the user's info.
SSO and AJAX / RIA applications often don’t go well together. With this type of application, you do not want to leave the page. The application is static and you get the data and do all actions through AJAX. Redirecting an AJAX call to a different website won’t because of cross-site scripting protection within the browser.
-With this solution the client only needs to attach the session by providing the server with a token generated by the broker. That attach request doesn’t return any information. After attaching the client doesn’t talk at all to the server any more. Authentication can be done as normal.
+## Examples
[![SSO Ajax](http://blog.jasny.net/wp-content/uploads/sso-diagram_ajax-241x300.png "sso-diagram_ajax")](http://blog.jasny.net/wp-content/uploads/sso-diagram_ajax.png)
The client check for the token cookie. If it doesn’t exists, he requests the attach URL from the broker. This attach url includes the broker name and the token, but not a original request URL. The client will open the received url in an <img> and wait until the image is loaded.
-The server attaches the browser session key to the user session. When it’s done it outputs a PNG image. When this image is received by the client, it knows the server has connected the sessions and the broker can be used for authentication. The broker will work as a proxy, passing commands and requests to the sso server and return results to the client.
+ php -S localhost:9000 -t examples/server/
+ export SSO_SERVER=http://localhost:9000 SSO_BROKER_ID=Alice SSO_BROKER_SECRET=8iwzik1bwd; php -S localhost:9001 -t examples/broker/
+ export SSO_SERVER=http://localhost:9000 SSO_BROKER_ID=Greg SSO_BROKER_SECRET=7pypoox2pc; php -S localhost:9002 -t examples/broker/
+ export SSO_SERVER=http://localhost:9000 SSO_BROKER_ID=Julias SSO_BROKER_SECRET=ceda63kmhp; php -S localhost:9003 -t examples/ajax-broker/
-## To conclude
+Now open some tabs and visit http://localhost:9001, http://localhost:9002 and http://localhost:9003.
-By connecting sessions, you give the broker the power to act as the client. This method can only be used if you trust all brokers involved. The login information is send through the broker, which he can easily store if the broker has bad intentions.
+_Note that after logging in, you need to refresh on the other brokers to see the effect._