Layered Tech is committed to being the leader of the Hosted Infrastructure market by providing our customers with the best products backed by the best service.  In an effort to improve our customer experience, we have determined that a small number of existing servers will need to be relocated from their current data center.  As you are receiving this message, we have identified that you have one or more servers in the in area of the Savvis facility that will need to be moved.  It is our intention to minimize any interruption in service and we will do our best to work within predetermined time frames that are convenient to you.


Due to the form factor (chassis type) of this server, we will need to migrate your data to a new server. We will work with you so that the impact is as minimal as possible.  

Below are the servers that are affected by this migration.  Please respond to this message acknowledging the need to relocate your server(s).  At that point, we will move this ticket to our Operations Department where we will work with you on a migration schedule.

• The Secure Site has a pre-shared key (PSK) that the SSO Server assigns, this key gets hardcoded in the Secure Site and kept private, it never gets passed between the parties during normal authentication requests.
• The Secure Site has a siteid that is simply a number that uniquely identifies it to the SSO Server.  This too gets assigned by the SSO Server and does not change for the life time of the site.
  
• Encryption gets done using a simple symmetrical algorithm, the PSK is the passphrase.
• The SSO server knows what domain name a site is in, the SSO Server will use this to validate auth requests and generate redirects based on this domain name only.

1. The user tries to access the Secure Site
2. Secure Site generate a unique single use token, and saves it in a Session
3. The Secure Site redirect the browser to the SSO server with a request that has the siteid unencrypted and a encrypted string containing the URL the browser should go to if he is authenticated correctly by the SSO Server and also the Token generated in step 2.
4. The SSO Server validates the request, checking Next URL against that stored for siteid after using the PSK stored for siteid to decrypt the packet.
5. The user is presented with a login form.  The login form shows detail about the Secure Site such as its URL, a description of the site and who to contact with any support requests about this site.  The user is warned that his personal details will be shared with the site.  The user logs in with a username and password and gets redirected to the Secure Site.
6. The Secure Site gets a authentication packet in the redirect that has - encrypted using the PSK - the username, email address, real name, time zone and the previously generated token.  In unencrypted form is a md5 hash of all the private information concatenated with the PSK, this is signature for the request and could be used as a cryptographic digital signature if the SSO Server is configured to not encrypt the private data.  The Token gets removed from the session and the user gets marked as Logged In using a cookie or existing session.
   
7. At this point the user is logged in and can access the Secure Site, the Secure Site knows his private details and can associate his data with him.  From this point on it's a standard cookie based auth and the Secure Site can decide how long the login session is valid for etc.

• Define the PSK, SSO Server URL and your unique ID, all of this will be supplied by the SSO server when you register your site.
• Start a session - this is used to associate a one-time-use token that travels between the SSO client and Server, more on this later but it helps prevent session replay attacks.
• Check if we got the data that the SSO server will typically pass us $_GET['authdata'] and $_GET['v'], if we did get it, start up a SSO client and authenticate.  Showing the protected page on success or an error message if it failed.
• If the GET parameters aren't present it is either a first visit or a returning visit, the SSO Client lib gets used to find out if its a returning visit and shows some personal information if the user is logged in, else presents the user with a bit of guest info and a link to the login form.  Again here the SSO client library generate all the needed URLs and encryption and what not.

        <Directory "/usr/share/nagios">
               AuthType Apache::Auth_pSSO
               AuthName pSSO
               PerlAuthenHandler Apache::Auth_pSSO->authenticate
               require valid-user
               PerlSetVar pSSO_PSK "goG4mUrJeacE7VyidEfd"
        </Directory>

var = nil
value = nil
facts = {}

if File.exists?("/etc/facts.txt")
        File.open("/etc/facts.txt").each do |line|
                var = $1 and value = $2 if line =~ /^(.+)=(.+)$/
                if var != nil && value != nil
                        facts[var] = value
                        var = nil
                        value = nil
                end
        end

        facts.each{|var,val|
                Facter.add(var) do
                        setcode do
                                val
                        end
                end
        }
end

• Server and Client libraries in PHP but also client libraries in other languages.
• Should store Real Name, Email Address, Time Zone and possibly other bits of information and share it on demand with other sites.
  
• Work cross domains, so a single SSO server should be able to serve all my sites and possibly those of 3rd parties should they wish to.  This basically means the SSO server shouldn't just go and set a domain cookie.
  
• Have a good management system where users can manage their identities in a self-service manner.
• Client sites should be registered with the server before they can use the SSO system.  When a users identity is accessed he should be shown information about description, contact details etc. it should be completely open to the user when his information gets shared and he should be able to say no.
  
• The server should keep a log of all uses of the identity, in practice only the first requests do get logged, after that the user can be kept logged in on the clients and so new requests do not get made to the server.
• Authentication should be modular so you can plug any user database into the server.  For instance I can share a single database between my imap, pop, smtp, ticketing system and any of my sites using the SSO system.
• Legacy applications and third party applications that rely on standard HTTP Authentication should be able to use it, at least when run under Apache.  I want to be able to log into Cacti, Nagios, RT and others with a single login.
  

$result = $foo->getBar();

$result = $foo['bar'];

$_GET = new ArrayArmor($_GET);

print ("Filtered Variable:$_GET[test]<br>\n");
print ("Unfiltered Variable: " . $_GET->getRaw("test"));

Filtered Variable: 1234\';delete from accounts;--
Unfiltered Variable: 1234';delete from accounts;--