Originally I wanted to publish restricted sites under the web.xml and take advantage of HTTP's existing authorization and authentication functions. This way 401 or 403 errors would be produced on trying to type in restricted URLs without authentication. However I have not found a way to use these basic authentication schemes (Basic, Form-based, digest and Client Certificate) without implementing a username and password and leaving all the authentication work to be done by these schemes even though authentication is already being done by OpenID.
The next method I looked at to restrict site access was using the SessionID. So as it stands, as soon as ED receives the the authentication from the OpenID Provider and ED has verified it, ED sets a sessionID cookie for the user. So long as that cookie exists, the user may access ED without re-logging in. On logging out, the sessionID cookie is destroyed and the session is invalidated. This method requires that at every restricted page there be a check to determine if cookie sessionID from the client and the sessionID from the server match. If the session is invalid or the cookie sessionID does not match, the user is redirected to the login page.
Cookie Theft
The major concern with keeping a cookie for the sessionID is that a person may determine the sessionID from packet sniffing, leading to possible impersonation of a user. One way around this is to use SSL or TLS which encrypts data going back and forth between the client and server, thus encrypting the cookie. This service is requested of the Web Server which hosts your website.
If anyone has any other thoughts on how to implement security, I would be more than happy to hear it.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment