RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2
Added as JIRA #217: http://opensource2.atlassian.com/projects/spring/browse/SEC-217 Paul, please feel free to watch this issue and add additional comments if desired. Thanks, Scott -Original Message- From: Ben Alex [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 4:27 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Preparing for 1.0.0 RC2 [EMAIL PROTECTED] wrote: Paul, I know it's been 3 weeks since you sent this and I'm sorry not to have replied. I have a number of professional and personal obligations taking all of my time. If anyone else has a change to review Paul's proposal, please feel free to do so. I plan to get back involved after my other obligations have been completed, but it will probably be 1-2 more months until I can contribute any measurable time. Sorry for the inconvenience, Hi Scott and Paul I just checked and cannot see this in JIRA. Would one of you please log a summary of the discussion into JIRA together with the proposed fix. That way it can be tracked, and if I get time before Scott does, I'll review the fix. Cheers Ben --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=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
Paul,
I know it's been 3 weeks since you sent this and
I'm sorry not to have replied. I have a number of professional and
personal obligations taking all of my time. If anyone else has a change to
review Paul's proposal, please feel free to do so. I plan to get back
involved after my other obligations have been completed, but it will probably be
1-2 more months until I can contribute any measurable time.
Sorry for the inconvenience,
Scott
From: Garvey, Paul M (GE Comm Fin)
[mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 12:50
PMTo:
acegisecurity-developer@lists.sourceforge.netSubject: RE:
[Acegisecurity-developer] Preparing for 1.0.0 RC2
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.
bean id="authenticationProcessingFilter"
class="com.ge.comfin.ess.webapp.filter.DerivedSiteminderAuthenticationProcessingFilter"
property name="authenticationManager"
ref="authenticationManager"/
property name="authenticationFailureUrl"
value="/login.jsp?error=true"/
property name="defaultTargetUrl"
value="/mainMenu.html"/
property name="filterProcessesUrl"
value="/j_security_check"/
property name="siteminderUsernameHeaderKey"
value="HRID"/
property name="siteminderPasswordHeaderKey"
value="HRID"/
property name="formUsernameParameterKey"
value="j_username"/
property name="formPasswordParameterKey"
value="j_password"/
property name="rememberMeServices"
ref="rememberMeServices"/
/bean
public classDerivedSiteminderAuthenticationProcessingFilter
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
PMTo:
acegisecurity-developer@lists.sourceforge.netSubject: 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
AMTo:
acegisecurity-developer@lists.sourceforge.netSubject: RE:
[Acegisecurity-developer] Preparing for 1.0.0 RC2
Scott,
You are partially right
I shou
RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2
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.
bean id="authenticationProcessingFilter"
class="com.ge.comfin.ess.webapp.filter.DerivedSiteminderAuthenticationProcessingFilter"
property name="authenticationManager"
ref="authenticationManager"/
property name="authenticationFailureUrl"
value="/login.jsp?error=true"/
property name="defaultTargetUrl"
value="/mainMenu.html"/
property name="filterProcessesUrl"
value="/j_security_check"/
property name="siteminderUsernameHeaderKey"
value="HRID"/
property name="siteminderPasswordHeaderKey"
value="HRID"/
property name="formUsernameParameterKey"
value="j_username"/
property name="formPasswordParameterKey"
value="j_password"/
property name="rememberMeServices"
ref="rememberMeServices"/
/bean
public classDerivedSiteminderAuthenticationProcessingFilter
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
PMTo:
acegisecurity-developer@lists.sourceforge.netSubject: 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
AMTo:
acegisecurity-developer@lists.sourceforge.netSubject: RE:
[Acegisecurity-developer] Preparing for 1.0.0 RC2
Scott,
You are partially right I
should not have to extend the SiteminderAuthenticationProcessingFilter to
makeAcegi 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
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 AMTo: acegisecurity-developer@lists.sourceforge.netSubject: RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2 Scott, You are partially right I should not have to extend the SiteminderAuthenticationProcessingFilter to makeAcegi 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 toget authenticated in Acegi is if theAttemptAuthentication() 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 McCrorySent: Thursday, February 09, 2006 9:14 PMTo: acegisecurity-developer@lists.sourceforge.netSubject: Re: [Acegisecurity-developer] Preparing for 1.0.0 RC2 Paul, I don'textend 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 leftme much room for non-essentials. It's also inefficientfor me to monitor and collate all the messages on the Spring mailing list, Acegi's mailing list, Acegi's message boards andprivate 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=lnkkid=103432bid=230486dat=121642 ___ Home: http:/
RE: [Acegisecurity-developer] Preparing for 1.0.0 RC2
Scott, You are partially right I should not have to extend the SiteminderAuthenticationProcessingFilter to makeAcegi 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 toget authenticated in Acegi is if theAttemptAuthentication() 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 McCrorySent: Thursday, February 09, 2006 9:14 PMTo: acegisecurity-developer@lists.sourceforge.netSubject: Re: [Acegisecurity-developer] Preparing for 1.0.0 RC2 Paul, I don'textend 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 leftme much room for non-essentials. It's also inefficientfor me to monitor and collate all the messages on the Spring mailing list, Acegi's mailing list, Acegi's message boards andprivate 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=lnkkid=103432bid=230486dat=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
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! ;-)ScottQuoting 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=lnkkid=103432bid=230486dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
