snapcount: "
This is a very interesting concept but it seems like this is a very dangerous implementation.  Say for example you have a savvy user who edits their cookie to contain the username 'admin'.  That could be bad...

An alternative approach (maybe you thought of this, just throwing it out there) would be this:

1) If the cookies not there, redirect to SSO script


2) Authenticate user


3) If they authenticate, store their username in a db on the SSO server with a sessionId (SSO server would autogenerate random unique id, preferably a GUID).

sessionId + username
------------------------
kv38dF    -    joeblow


4) Return the sessionId and username to webgui (or whatever app its going to).


5)  Your  webgui macro and other apps query the username associated with the id from the SSO server.  (select username from ssoSessions where sessionId='kv38dF')


6) Compare the username  set in the cookie with the username returned by the query.  If they match,  set their  webgui session to the username

Now a malicious person not only has to guess a valid sessionId, but they also have to guess the user that is associated with it as well. 

You could even set a timeout in the sso system via a timeout column and check that that's valid as well in your macro.

This seems to be much safer all the way around.  In any case, cool idea and thanks for contributing this to the community!  I had never considered doing this before but the idea of logging in once for everything sure sounds nice =)    

I just realized I typed a goof =P  When I say return the values to WebGUI or another app, what I really mean is to set them in the cookie... 
"

isaac: "Thanks for helping to highlight the security angle of this macro!  It needs to be considered and thought out by anyone that would look to implement any feature like this.
It is my intention that the macro be modified prior to deployment in a live system, which is why I left several parameters defined in the code and not passed in as macro parameters.
 
Your comment on SSO sessions is a good way to go, and is widely used.
Another way, which is what we use, is to sign the cookie and have the signed cookie contain user information. This way the web application (the macro in this case) can validate the authenticity of the cookie itself, without needing access to the SSO systems (it might not be deployed where it can have access to the SSO system!).  In this way the SSO cookie can be used by systems on segmented networks with different security levels, but also verify that the cookie has not been tampered with.

"

ehab: "This is a very interesting macro, if you ever create a new way of doing this please post it."