Understanding j_security_check 'under the hood'


Web tier: servlets, JSP, Web frameworks: Understanding j_security_check 'under the hood'

  1. Hi,

    I am interested to know how the j_security_check mechanism works (or has been implemented by vendors) in the latest servlet specification. It seems to me that j_security_check is a very under-documented feature and I would really like to know what is going on under the hood before diving in to it.

    From what I gather, when logging in to a web server using the j_security_check mechanism the user's credentials are automatically checked by the webserver against whatever authentication service you specify. If authentication is successful the user's credentials are then associated with the current thread - the user is now part of the J2EE security architecure (ie. they can now try accessing EJBs with authorisation taken care of automatically by the architecture). However, how does the webserver reassociate the same user with a thread when they reaccess the webserver?...

    ...Does the webserver have to check against the authentication service again?
    ...Is an encrypted token sent back to the browser?

    Can anyone shed some light on this for me?

  2. Hi Myles,

    How j_security_check works is vendor specific. Here is my experience with WebLogic.

    Once j_security_check authenticates a user, it creates an HttpSession object and stores an authentication object in the session (from my debugger: weblogic.security.acl.internal.AuthenticatedUser). This object contains user specific information, like name, ssl certificate (if certificat authentication was used), and time stamp. The user is sent back a cookie with the session id (if cookie's are supported). Subsequent access by the same user will send the cookie as part of the request. The session id will be extracted from the cookie and used to lookup the user's session. If the session contains an authentication object, then the user's auth information will be attached to the thread.

    Those are my obverstaions...hope it helps.

  3. Thanks Andy, that explanation is really helpful. Do you know how the user's credentials are attached to the thread though? I would like to know the mechanism as we are thinking of developing are own sign-in mechanism instead of using j_security_check. Is it done in a standard J2EE/Java way?

  4. That's a good question. I'm not sure how this is done, but I haven't read of any "standard" way of doing it. I'm pretty sure that each container provides its own mechanism for attaching authorization information to a thread. What I've seen that is standard is how you access this information from an EJB or servlet/jsp.

    If you want to roll your own sign-on mechanism, you may be able to get away with just producing the same results that j_security_check produces. This would mean creating the HttpSession object and storing the same authorization token in the session that j_security_check stores.

    Another alternative would be to include or forward the login request to j_security_check.

  5. Hi, I am new to weblogic, I have used j_security_check as the submit action for my login form As soon as I click on submit it gives me the foll error screen -------------------------------------- Error 404--Not Found From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.4.5 404 Not Found The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. ----------------------------------------------- I am not able to understand y is the server not able to find it Do i hv to explicitly create j_security_check somewhere if yes , can u gfive me a sample code Pls help Thnx in advance