Michael,
Thanks for taking the time to check the security systems of J2. The more
eyes the better!
However, I believe that these concerns are not as significant as one
might think at first glance.
1. If you are using J2 as a SSO solution, you should be using HTTPS/SSL
for the portal and all content aggregated by the portal. This will
upgrade the connections under most normal conditions to ensure user
credentials are not "in the clear". The redirects in J2 are no more or
less secure than the initial post in login portlet. The redirects and
form entry techniques are designed to implement the standard JAAS
container authentication model and are widely used.
2. AFAIK, the redirect pages are specifically NOT cached or included in
the browser history. Browsers are explicitly instructed not to cache to
any portal requests. This should ensure that after a session is closed,
no memory of the portal session should persist.
Please let us know if you see any behavior to the contrary. AFAIK, J2
uses no technique that is not employed commonly on secure websites. It
is designed to be a solid SSO solution... this is certainly a common
portal use case!
Let us know if you see any other suspect behavior,
Randy
Michael Gustav Simon wrote:
Hi J2-Users,
to integrate J2 as a "SingleSignOn"-Client, I analyze the login process in
detail.
I think that the redirect to the login.jsp from the LoginJSPViewValveImpl in
the LoginPipeline is not secure.
The username and password will be send to the client in plain text!
The javascript in the body tag will post the data to the servlet container
with the javascript call onload.
...
<body onLoad='document.forms["login"].submit();'>
...
What is about the browser cache?
mg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
