RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2

Garvey, Paul M (GE Comm Fin) Mon, 13 Feb 2006 09:51:16 -0800

Scott,

This is my recommendation, the following snippets below shows how I cleanly got Siteminder/Acegi to work.

Look at the requiresAuthentication() method below it should be overridden by the SiteminderAuthenticationProcessingFilter

instead. Do you have an issues or concerns with the requiresAuthentication() method ? That is the only change I had to make.

At the end of the day the requiresAuthentication() method CAN NOT expect to attempt authentication when it get a j_security_check"

url and so that is why my version of the requiresAuthentication() method also checks for the (getDefaultURL() && NOT authenticated)

if that _expression_ evaluates to TRUE then an attempt to authenticate will ensue.

public class DerivedSiteminderAuthenticationProcessingFilter extends SiteminderAuthenticationProcessingFilter {

private static final Log logger = LogFactory.getLog(DerivedSiteminderAuthenticationProcessingFilter.class);

    public DerivedSiteminderAuthenticationProcessingFilter() {
        super();
    }

    protected boolean requiresAuthentication(HttpServletRequest request,
        HttpServletResponse response) {
        String uri = request.getRequestURI();
        int pathParamIndex = uri.indexOf(';');

        if (pathParamIndex > 0) {
            // strip everything after the first semi-colon
            uri = uri.substring(0, pathParamIndex);
        }
        //attempt authentication if j_secuity_check is present or if the getDefaultTargetUrl()
        //is present and user is not already authenticated.
        boolean bAuthenticated = false;
        SecurityContext context = (SecurityContext)request.getSession().getAttribute(HttpSessionContextIntegrationFilter.ACEGI_SECURITY_CONTEXT_KEY);
        if (context != null) {
         Authentication auth = context.getAuthentication();
         if (auth != null && auth instanceof UsernamePasswordAuthenticationToken) {
          UsernamePasswordAuthenticationToken token = (UsernamePasswordAuthenticationToken)auth;
          bAuthenticated = token.isAuthenticated();
         }
        }
        //if true is returned then authentication will be attempted.
        boolean bAttemptAuthentication = (uri.endsWith(request.getContextPath() + getFilterProcessesUrl())) ||
                                        ((uri.endsWith(getDefaultTargetUrl()) && !bAuthenticated));
        if (logger.isDebugEnabled()) {
            logger.debug(
                "Authentication attempted for the following URI ==> " + uri + " is " + bAttemptAuthentication);
        }
        return bAttemptAuthentication;
    }

}

Paul

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Saturday, February 11, 2006 3:18 PM
To: acegisecurity-developer@lists.sourceforge.net
Subject: RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2

Paul,

What would you recommend instead? The only other option off the top of my head would be to make sure the filter is executed upon every request.

Scott

From: Garvey, Paul M (GE Commercial Finance) [mailto:[EMAIL PROTECTED]
Sent: Friday, February 10, 2006 11:28 AM
To: acegisecurity-developer@lists.sourceforge.net
Subject: RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2

Scott,

You are partially right I should not have to extend the SiteminderAuthenticationProcessingFilter to make Acegi work with Siteminder.

The reason I was left with no choice was the fact that my index.jsp contains "<c:redirect url=""/>" and so when the

requiresAuthenitcation() method sees the URL "mainMenu.html" because it is not "j_acegi_security_check" or "j_security_check" in the case of

appfuse apps, it doesn't call attemptAuthentication(). So that is why I had to override requiresAuthenitcation() so in addition to checking

for the URL to be "j_secuirty_check" the method also checks if URL is "mainMenu.html" && contextHolder is missing to call AttemptAuthentication()

method.

I don't like the solution of doing the secuirty check in my base action class because that means that Acegi is now coupled with my action code and

while that might work fine for you I would rather like to see SiteminderAuthenticationProcessingFilter modified to cleanly integrate with Siteminder.

Siteminder sends only the username in the request header but not the "j_security_check" URL. How can we send a "j_security_check" to the

requiresAuthenitcation() without first going to the login page this is the only?

The only way to get authenticated in Acegi is if the AttemptAuthentication() method gets called. Based on the Acegi/Siteminder integration documentation

user will be redirected to the login page every time before they can be authenticated. This in MHO is a flaw in the SiteminderAuthenticationProcessingFilter

requiresAuthenitcation() method with ONLY authenticates when it receives the "j_security_check" URL. In the case of Siteminder the requiresAuthenitcation() method

has to be refactored to accommodate the fact that Siteminder has already done the authentication and a "j_security_check" is not necessarily the ONLY signal

that the attemptAuthentication() method should be called.

Scott,

- Paul

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott McCrory
Sent: Thursday, February 09, 2006 9:14 PM
To: acegisecurity-developer@lists.sourceforge.net
Subject: Re: [Acegisecurity-developer] Preparing for 1.0.0 RC2

Paul,

I don't extend SiteminderAuthenticationProcessingFilter and override the requiresAuthentication() method because every one of my protected action classes first checks to see if the user is authenticated (i.e. has an security context holder) before processing the request. I do this by calling a method in my base action class. If that base class method fails to find a security context holder, it redirects the user to j_acegi_security_check, thus invoking the Siteminder filter. This approach works very well for us, and if you'd like to try it, let me know and I'll be glad to post the code.

Sorry it took a few days to respond, but please understand that continuous 16-hour days hasn't left me much room for non-essentials. It's also inefficient for me to monitor and collate all the messages on the Spring mailing list, Acegi's mailing list, Acegi's message boards and private messages, especially after I thought we already had a dialog using my work email account. Ultimately it really doesn't matter to me which venue it is, but lets try to stick to one instead of expecting all of them to be checked - I gotta sleep sometime! ;-)

Scott

Quoting Ben Alex <[EMAIL PROTECTED]>:
> Garvey, Paul M (GE Commercial Finance) wrote:
>> All, Does anyone know if there is any plan to fix/investigate the
>> Siteminder/Acegi integration issue I posted a few days ago.
>> I made any attempt at fixing the issue but would like to know if anyone
>> looked at it.
>>
>> http://forum.springframework.org/showthread.php?t=22068
>> http://forum.springframework.org/showthread.php?t=22067
> Hi Paul
>
> Please feel free to post it to JIRA, that way it will get monitored.
>
> Best regards
> Ben
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Home: http://acegisecurity.org
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>

RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2

Reply via email to