J2EE container managed security

[Ryan Stewart]

I'm experimenting with container managed security and have a couple of
questions for those of you who use it or have decided not to use it.

1) Why do you use it or not use it? Do you find it versatile? Restrictive?

2) Why do I still have access to protected url-patterns after a
session.invalidate() when using basic authentication but not when using
form-based authentication?

3) Why, when using form-based authentication, would my test application not
redirect to the HTTPS port properly? I'm running Tomcat on the default 8080
with SSL on 8081. Redirects are set properly in server.xml. When using basic
authentication, I will be successfully redirected from
http://localhost:8080/secureApp/index.jsp to
https://localhost:8081/secureApp/blah (my secure resource). However, when I
change from basic to form-based (no other changes to web.xml), it tries to
send me to https://localhost:8080/secureApp/login.jsp for authentication.
Note the incorrect port. Will post whichever code upon request if I haven't
figured it out by then.

 

[Ryan Stewart]

I'm experimenting with container managed security and have a couple of
questions for those of you who use it or have decided not to use it.

1) Why do you use it or not use it? Do you find it versatile? Restrictive?

2) Why do I still have access to protected url-patterns after a
session.invalidate() when using basic authentication but not when using
form-based authentication?

3) Why, when using form-based authentication, would my test application not
redirect to the HTTPS port properly? I'm running Tomcat on the default 8080
with SSL on 8081. Redirects are set properly in server.xml. When using basic
authentication, I will be successfully redirected from
http://localhost:8080/secureApp/index.jsp to
https://localhost:8081/secureApp/blah (my secure resource). However, when I
change from basic to form-based (no other changes to web.xml), it tries to
send me to https://localhost:8080/secureApp/login.jsp for authentication.
Note the incorrect port. Will post whichever code upon request if I haven't
figured it out by then.

I should mention I'm running Tomcat 4.1.30.

 

[Oscar kind]

1) Why do you use it or not use it? Do you find it versatile? Restrictive?

I use it because it's easy: the application server decides if the user has
enough authorization. It's crude mechanism though; if, for example, you're
allowed to edit your own account but not somebody elses, your code must
force the retrieval and update of your own account.

It's easy, but cannot do everything. I find it not to be versatile, but I
don't expect it to be. But given it's limitations, I don't find it
restrictive either. However, I find I must keep in mind it's only part of
the security design for an application.

2) Why do I still have access to protected url-patterns after a
session.invalidate() when using basic authentication but not when using
form-based authentication?

Because the browser keeps sending the username/password combo for the
pages. IIRC, this is because for protected pages on a webserver, there is
no concept of a session.

3) Why, when using form-based authentication, would my test application not
redirect to the HTTPS port properly? [...]

I have no idea. I've only used HTTPS via a proxy: the client connects to a
proxy (HTTPS only), which redirects the request via HTTP. Since all
connections between the proxy and the application server (and between the
application server and the database) are behind a firewall, it's secure
enough.


Oscar