Username Password
Bookmark and Share

SingleSignOn Macro (webgui7)

UPDATE:  As JT pointed out while I was trying to work through some bugs on this.  This will not be possible to implement in this way. So please do not try to use this macro. I have left it here, in case anyone wants to look at the code.  But now I will continue to try to implement this functionality another way.


This macro is used to implement a single sign on function with WebGUI.

For our environment (enterprise, internal web systems), we populate a domain-wide cookie with authentication information when a user signs into the single sign on system (in our case, this is a simple CGI).  Our page templates in WebGUI contain this macro, which looks at the cookie and sets the session to the user found in the cookie.  This bypasses the WebGUI Authentication systems, and thereby causes several issues:

  1. Security is now no longer completely contained in WebGUI: webgui now must 'trust' that the information in this cookie is valid and secure.
  2. Since we override the session with the data found in the cookie, and admin cannot use the 'become this user' feature in the user management area. ( I would like to fix this, it's a very useful feature )

Despite this, we are very happy with how this works, since our other web tools have been made to recognize this cookie, a user only needs to login to once.

NOTE:  This macro must be modified prior to deployment to work with your environment. 

 P.S.  Thanks to Frank Dillon for his idea on this implementation during the WUC hackathon.


1.0.1 - fix to only reset session when the single signon cookie does not match the current session username 

System RequirementsPlease be advised: this contribution was tested with something older than WebGUI 7.5. When this contribution was uploaded there was no field for the author to fill out regarding it's requirements.
4snapcount: "
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... 
2isaac: "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.

5ehab: "This is a very interesting macro, if you ever create a new way of doing this please post it."
LinksNo Support Offered
Statistics Downloads: 939
Views: 5387
Rating: 4
Updated: 10/3/2006
Keywords macros
NavigationBack to the Bazaar
© 2022 Plain Black Corporation | All Rights Reserved