I think I found a bug in JBoss SSO SAML token validation but I'd like to post it here to get a confirmation first before creating a ticket.
I've got two SSO partner sites setup and it works fine. I am using the default demo IdentityProvider so the valid users are user1, user2, user3, hpotter, and the password for all of them is the same "password" text. Then I tried to perform a SSO auth programmatically by simulating a web browser using HttpClient. Here what I did:
1. Using browser to sign in on the sso site1 as user1. This will setup a cookie with the browser containing the SAML token. The token contains the "user1" subject name.
2. I then access a JSP page on sso site1 that uses HttpClient to retrieve a protected page on sso site2 with the following steps:
2.a) Create a HttpClient object and sets its cookie with the SAML token extracted from the request object.
2.b) Post to "/federate/" on sso site2 using the HttpClient. This passes the SAML token to the sso site2.
2.c). Using the same HttpClient object (it handles the cookie automatically) to access the protected page at sso site2.
2.d) This JSP page then displays the protected content retrieved from site2 to the browser.
The test worked as expected. I then did the following and found something interesting:
1. Before setting the SAML token cookie in the HttpClient object, I replaces the subject name "user1" with "user2". I expected to see an error when retrieving the protected page from sso site2 because the SAML token has been modified. However, I was still able to retrieve the protected content from sso site2, showing it is accessed as the authenticated user "user2".
2. I also tried "user3" and "hpotter" and they all went through as if authenticated as those users on sso site2.
3. I then tried a username that does not exist, "fakeuser". This time the secured content was not retrieved, it returned empty content instead. However, the "/federate/" on sso site2 didn't throw any error.
I don't know how the SAML token is validated between the federated servers. It seems that there is a bug which accepts invalid SAML token as long as the username exists (or maybe when the passwords are the same).
I also think the "/federate/" servlet should return error when the SAML token presented can not be validated.