I was working with a client today that wants to rework what their URL looks like, and actually try to put in session data into it. The reasons for this vary, and are irrelevant, but suffice to say this was a critical piece of functionality for their site. Initially, I said “absolutely – Webthority can do this!” knowing that I’ve used Webthority’s URL rewriting capabilities in the past.
However, as we put everything into place, nothing happened. And it turned out that the URL re-writing that they wanted (which is to put in the session id into the URL) wasn’t available until the user authenticated. That sort of ‘URL mangling’ only happened when an authentication agent was used! I’ve never used Webthority without one, which makes sense since it often used for Web SSO, and you always want to authenticate, right?
In any case, after a lot of stumbling and bumbling around, Paul H clued me into how the Custom Authentication Agent was used. The documentation is pretty scant on it, so I created this 2.5 minute video outlining the changes I had to make in order to get the user to automatically authenticate and establish a session.
This is where I came up with the term ‘promiscuous authenticator.’ In a perfect world, this would be another option, just like LDAP or Database. But for the time being, this will work.
http://www.idmwizard.com/quest/WebthorityCustomAuth/index.html
Hopefully, this will help others that are looking to configure Webthority’s Custom Authentication Agent.
Comments on this entry are closed.