Container-managed authentication

Hi,

I need to use container-managed authentication (need single sign-on for multiple webapps in the same container). But I'm a little confused as to how this works.

What I'd like to be able to do is to specify a general secure area '/secure/*' in web.xml that would require logging into the container, and then use the SecurityEnforcementFilter to protect specific urls.

I'm not sure if this is possible because SecurityEnforcementFilter uses an AuthenticationEntryPoint, and I'm not sure how to integrate that with container-managed security. Authentication should never fail in this situation because the user would presumably be logged in by the time they reached the SecurityEnforcementFilter, so I'm not sure what the purpose of the AuthenticationEntryPoint is in this case.


Also, in looking through the sample code, I noticed that the container-managed authentication has the BasicProcessingFilter turned on. (in samples/contacts/etc/ca/web.xml)

This doesn't really make sense to me, why have a basic authentication filter if the container is managing authentication?

Thanks for your help!

--Alex

Use of container adapters is strongly discouraged except in the most exceptional of circumstances, or if people need to transition an existing webapp to Acegi Security in stages. In either event, the goal is to use the embedded (non-container adapter) approach to authentication ASAP.

SecurityEnforcementFilter should not be used with container adapters. This is because the Servlet Specification's web.xml will define the protected URIs, not SecurityEnforcementFilter.

BasicProcessingFilter should not be defined in a web.xml being used with container adapters. In the current CVS HEAD this filter is not defined in the container adapter configuration.

If you need single sign on, have you looked at CAS? It will give you single sign on across both web applications as well as web containers, and when used with Acegi Security, this also gives you 100% web container portability. It will even authenticate non-Java web servers, like IIS and Apache.

Thanks for the information.

I've thought about trying CAS, but at this point, it seems way too complicated for the simple case that I'm trying to solve. (2 web apps: 1 mostly dynamic in a .war, 1 mostly static not in a war, that need to have single sign on)

When you say container adapters are strongly discouraged, do you mean that they will no longer be maintained in the future? The lack of portability isn't that big of an issue to me, especially in comparison to setting up CAS. But I don't want to use something that is going to be killed.

Also, I understand that web.xml specifies the protected URLs, but this is a very simple match. It would be nice to be able to leverage the regexp matching of SecurityEnforcementFilter. In my case, I would only use the filter to specific secure areas underneath the directories specified in web.xml, so there shouldn't be any weird interactions.

If this is possible, it still leaves the question of what should be done with the AuthenticationEntryPoint.

I'll answer my own question.

It is possible to use Container Adapters and SecurityEnforcementFilter together. For it to make sense, all the URLs protected by SecurityEnforcementFilter should be beneath the URL protected by the container.

You can use the AuthenticationProcessingFilterEntryPoint as the entry point. The loginFormUrl property of the entry point probably doesn't matter because the container is the 'entry point'. If your SecurityEnforcementFilter protects URLs that are outside of the container's protected area, then the loginFormUrl will come into play because thats where Acegi will redirect you if you are not logged in.


I've only been playing with this for a day, so there might be some hidden issues that I haven't come across yet. And Ben Alex says this is not a recommended approach, so use at your own risk.

Quote:

---

Originally Posted by aburgel

It is possible to use Container Adapters and SecurityEnforcementFilter together. For it to make sense, all the URLs protected by SecurityEnforcementFilter should be beneath the URL protected by the container.

---

Indeed, the fundamental problem with container adapters being used with SecurityEnforcementFilter is there is no way for a webapp to trigger the containers' authentication mechanism. If anyone is aware of a way, they'd just write an AuthenticationEntryPoint that triggers the container to perform authentication. If you're happy for a general URL mapping to be protected by the container, but specific internal mappings be protected by Acegi Security, this will work.

Quote:

---

Originally Posted by aburgel

I've only been playing with this for a day, so there might be some hidden issues that I haven't come across yet. And Ben Alex says this is not a recommended approach, so use at your own risk.

---

The container adapters path is not recommended just because IMHO the standalone, filter-based model is superior. It doesn't require configuration of the container, doesn't require JARs in container classloader locations, and is totally portable at the WAR level. Also, as identified above, there is no way of elegantly using the SecurityEnforcementFilter, meaning secure object invocations that require authentication rely on the container having already performed authentication before the secure object is called. If people can live with these constraints, they're free to use container adatpers. But for my projects I wouldn't use them.

Regarding CAS, its only real configuration constraint is it needs HTTPS. If you need to "install" a CAS implementation, it only really requires you to download the server deployment, follow the steps in the Acegi Security Reference Guide (to use Acegi Security as the PasswordHandler), and deploy it. It then means you have SSO across your entire organisation, across different web physical servers, and even different web server types (Java webapp servers, IIS, Apache etc).