Odd behaviour in SSO-product

November 24, 2005

...

I am currently working on deploying eTrust SAML Affiliate Agent (Computer Associates) for a customer , and found myself totally baffled by its behaviour. In the solution in question,
we are running a web server in front of our application server. The SAML Affiliate Agent runs as a plugin on the web server. When users are authenticated by SiteMinder via the Affiliate Agent, the Affiliate Agent will insert user identity into the HTTP header that is forwarded to the application server. On the application server, we use this header to assert the user’s identity.

The basic idea with the concept of transferring user identity in the HTTP request header, is that trust is established between the Affiliate Agent and the application. In other words, the application trusts, without proof, that the header information it receives is correct. In so doing, it trusts that the Affiliate Agent handles this correctly. (This is sometimes referred to as perimeter authentication). So far, so good.

It turns out, though, that if the Affiliate Agent is configured not to enforce authentication (thereby allowing anonymous users to access resources in the application), it allows identity information to pass through from the user agent to the application! This means that any rogue client can impersonate any user by inserting a user name into the HTTP request as the application server will assume that the user was authenticated by the Affiliate Agent! The configuration is completely insecure, I would say wide open. What the Affiliate Agent should do, but which it doesn’t, is to check for incoming headers in the request, and act on it. The best thing to do, is to log the event and deny access to the application.

Be careful out there, kids.


Profile picture

Written by Vidar Kongsli who is a software professional living in Oslo, Norway. Works as a consultant, system architect and developer at Bredvid. You should follow him on Twitter