Re: [Acegisecurity-developer] IllegalStateException On Login

2007-04-25 Thread Baz
On 25/04/07, Murthy Avvari [EMAIL PROTECTED] wrote:
 Hi,

 I have been trying to fix this specific problem for my client who is using
 acegisecurity 1.0.3 for their web aplication running under Tomcat 5.5.x
 version.
 Here is the problem reproducing sequence.

 1. Set the session time out to just 1 Minute in Tomcat web xml
 configuration.
 2. Go to Login page. Enter Username and password but dont hit the submit
 button.
 3. Wait for little over 1 Minute.
 4. Hit the Submit button.

 Now I get the following exception. I am not sure is this the problem in

 1. Acegisecurity package?
 2. If yes, because The AbstractProcessingFilter is not configured as the
 First Filter?

 I really appreciate any help on this please.


As Ray said, this is unlikely to be an Acegi issue, but I since have a
filter sitting around to trace those errors, here it is. Not
appropriate for production use, YMMV, etc. It might help track the
problem down though.

All this does is track down stray writes within your application, and
it should be the first filter applied to '/*'. There's other kinds of
illegal state, like grabbing the outputstream then the writer for the
response, which I'm not tracking here but are easy to find in a
similar way.

Hope this helps,
Baz

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.FilterConfig;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.Filter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;
import java.io.ByteArrayOutputStream;
import java.io.CharArrayWriter;
import java.io.IOException;
import java.io.PrintWriter;

/**
 * This class buffers output to a servlet response and attempts to
 * prevent dodgy write-before-redirect errors. Any attempt to perform
something that
 * would reach an illegal state causes the buffer to be reset and the
position of both
 * the first write and the subsequent illegal operation to be logged.
The one exception
 * is if you do a 'flush()', required for some of the screens that
dump logging output.
 * Those cause the response to be committed early whatever happens.
 */
public class EarlyWarningFilter implements Filter {
private static final Log log = LogFactory.getLog(EarlyWarningFilter.class);
public void destroy() {}
public void init(FilterConfig filterConfig) {}

public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) throws IOException, ServletException {
if (request instanceof HttpServletRequest  response
instanceof HttpServletResponse) {
InstrumentedResponse instrumentedResponse = new
InstrumentedResponse((HttpServletResponse) response);
chain.doFilter(request, instrumentedResponse);
instrumentedResponse.flush();
} else {
chain.doFilter(request, response);
}
}

private static class InstrumentedResponse extends
HttpServletResponseWrapper {
private InstrumentedPrintWriter writer;
private InstrumentedServletOutputStream stream;
private boolean committed = false;
private IllegalStateException thrown = null;

public InstrumentedResponse(HttpServletResponse httpServletResponse) {
super(httpServletResponse);
}

public void sendError(int i, String name) throws IOException {
commit();
resetWithWarning(tried to sendError() after write());
super.sendError(i, name);
}

private void commit() {
if (!committed) {
committed = true;
thrown = new IllegalStateException(A second call to a
commit method occurred, this was first:);
} else {
thrown.printStackTrace();
}
}

public void sendError(int i) throws IOException {
commit();
resetWithWarning(tried to sendError() after write());
super.sendError(i);
}

public void sendRedirect(String name) throws IOException {
commit();
resetWithWarning(tried to sendRedirect() after write());
super.sendRedirect(name);
}

public ServletOutputStream getOutputStream() throws IOException {
if (stream == null) {
stream = new
InstrumentedServletOutputStream(super.getOutputStream());
}
return stream;
}

public void reset() {
resetWithWarning(Tried to reset() response after write);
super.reset();
}

public void resetBuffer() {
resetWithWarning(Tried to resetBuffer() response after
write (this might be ok!));
super.resetBuffer();
}

public void

Re: [Acegisecurity-developer] How to prevent brute force attack

2006-10-04 Thread Baz
On 10/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 It seems that you should only be able to access the change password page if 
 you are either:

 1.) Previously successfully authenticated
 2.) Required to authenticate as part of change password.

There is a third option. I worked on one site where 'change password'
was implemented pretty much identically to 'password reset', ie we
send you a URL that, for a limited time, will let you change your
password (and can only be used once). The reasoning behind this was:
- password reset needs to be done this way for subscribed users
anyway, to keep this issue away from the helpdesk. I was point-blank
refusing to implement the alternative solution, store the password in
plain text and mail it back :)
- with only one way to change the password, there's less code to
audit. All of the use cases - subscribe, forgot password, expired
password, user-initiated password change - worked the same way.

So, I guess my interpretation of the best practice for password change ...

My interpretation: get out of the game of managing passwords
completely - use single sign on with some central authentication
authority (like CAS, Athens, etc). And if one is not already
available, consider putting a central authority like CAS in place
instead of writing it into your app*.

Cheers,
Baz

* ok so customer requirements do sometimes get in the way here :) ...
but you did ask.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


[Acegisecurity-developer] SAML patent doesn't require paperwork any more

2006-05-16 Thread Baz

Its only tangentially related to acegi, and the rest of you might have
seen this already, but RSA have relaxed the licensing conditions for
their SAML patents:
http://lists.oasis-open.org/archives/security-services/200605/msg00014.html

This is pretty much the same as before (royalty-free if you don't sue
us) but they've dropped the requirement for getting the license
agreement signed by a board member - or in the usual integration
scenarios, signed by members of the board of each company involved...
which took forever. Its now pretty much as free as ASL 2.0 stuff
(which has a similar patent defense clause), but the same clause still
makes SAML GPL-incompatible.

Still, superb news.

-Baz


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


Re: [Acegisecurity-developer] SVN Commit Messages

2006-04-27 Thread Baz
On 4/28/06, Carlos Sanchez [EMAIL PROTECTED] wrote:
 Check it out here:
 http://jira.codehaus.org/browse/DOXIA-59?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel


I don't see the subversion tab there... is it a project permissions
thing? I'm logged in to JIRA. The tabs I see are:
  All CommentsWork LogChange History

But over on apache I can see it working (without logging in):
http://issues.apache.org/jira/browse/GERONIMO-310?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel

There I see these tabs:
All   CommentsChange History  Subversion Commits

-Baz


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


Re: [Acegisecurity-developer] Strange Bug Acegi + CAS3

2006-03-30 Thread Baz
Any chance you can get hold of the Host: header that came in with this:
13:56:46,799 DEBUG ChannelProcessingFilter:157 - Request:
https://cn1983:7443/CreditsWebApp/html/authentication/debug.jsp ;
ConfigAttributes: [REQUIRES_SECURE_CHANNEL]

... and the Location: header sent to you by CAS? (the Location header
should be like: https://cn1983:8443/... and the Host header needs to
be cn1983:8443 ; if the first one's wrong the bug is in CAS, if the
second one's wrong the bug is in the browser.

In any case, you ought to be able to work around this on tomcat: set
proxyHost and proxyPort for your application:
http://tomcat.apache.org/tomcat-4.1-doc/proxy-howto.html

... even though you're not using a proxy, this *should*[1] force tc to
pass your app the correct serverName/serverPort.

Failing that: you can add your own servlet filter that passes a
HttpServletRequestWrapper down the chain, with the correct host and
port; that bandaid should get your release out the door.

Cheers,
Baz

[1] I say *should*, but in the past and the tomcat people refused to
fix bugs with the port not being set:
http://issues.apache.org/bugzilla/show_bug.cgi?id=11748
(NB even though they said the buggy connector was deprecated, the code
with the bug was copied directly into the new connector) I don't know
if things have moved on since then, but you're using TC4 for the
application so this is likely to hit you.

On 3/30/06, Lucas Opara [EMAIL PROTECTED] wrote:
 I have a strange bug with cas and acegi.

 I have configured 2 tomcats server on the same machine called cn1983.
 A tomcat 4.1.29 for hosting my web application protected by acegi/CAS.
 A tomcat 5.0.28 for hosting CAS.war.

 tomcat 4 uses port 8443 for SSL.
 tomcat 5 uses port 7443 for SSL.


---
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=lnkkid0944bid$1720dat1642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


[Acegisecurity-developer] CAS configuration

2006-03-16 Thread Baz
Hi all,
I've been implementing acegi integration with Eduserv Athens[1] and
have been chatting to Luke about some oddities in the CAS integration
(Athens and CAS are quite similar, so I was getting up to speed by
browsing the code). A couple of these have been raised as bugs[2] but
there's other bits I'd like to ask about.

- is org.acegisecurity.ui.cas.ServiceProperties.get/setService() required?
It seems to me that this duplicates configuration elsewhere, since it
can only have the value that would be calculated by this method (if
you add this to CasProcessingFilter):
public String getService(HttpServletRequest request) {
int serverPort = request.getServerPort();
String scheme = request.getScheme();
StringBuffer sb = new StringBuffer(scheme);
sb.append(://);
sb.append(request.getServerName());
if (!(serverPort == 80  http.equalsIgnoreCase(scheme))
 !(serverPort == 443  https.equalsIgnoreCase(scheme))) {
sb.append(:).append(serverPort);
}
sb.append(request.getContextPath());
sb.append(getFilterProcessesUrl());
return sb.toString();
}

(incidentally a similar fragment to this is duplicated throughout the
acegi code, pretty much everywhere PortResolver is used?)

In the current setup, you can't use this code because
CasProxyTicketValidator.confirmTicketValid() doesn't get access to the
request. However, it's only called from
CasAuthenticationProvider.authenticateNow, which has access to
WebAuthenticationDetails constructed from the request, so the filter
can make this information available there?

The other thing I wanted to ask about isn't specific to CAS. I'd
extended AbstractProcessingFilter and implemented
AuthenticationEntryPoint as separate classes, much the same as all the
rest of the com.acegisecurity.ui packages. However I noticed that
these both required the same config information, and simply making a
single class that 'extends AbstractProcessingFilter implements
AuthenticationEntryPoint' took the entry point down to 2 lines of
code.

Looking at the other ui packages, it seems that there is a similar 1:1
correspondence between filters and entry points, with the duplicate
config issue being handled in different ways (Basic+Digest auth
delegates from the filter to the entry point, CAS uses
ServiceProperties to factor out the common code)

Looking at this, and the way that the 'Filter' classes aren't really
(the lifecycle methods arent used, and they're all marked 'do not use
directly') shouldn't all of these implement something like:

public interface AuthenticationFilter { // not a javax.servlet.Filter
// each filter is its own entry point.
public void commence(ServletRequest request, ServletResponse response,
AuthenticationException authException)
throws IOException, ServletException;
// the acegi filters are all http-only.
void doFilter(HttpServletRequest request, HttpServletResponse
servletResponse, javax.servlet.FilterChain filterChain) throws
java.io.IOException, javax.servlet.ServletException;
}

I can that in the code sometimes things identical interfaces have been
split for type safety (like AuthenticationEntryPoint and
ChannelEntryPoint) but I can't see why this argument hasn't been
applied to the Authentication Filters, since they can't be used as
servlet filters.

I've seen the 'servlet-container-managed' stuff in FilterToBeanProxy,
but to me this looks like something that can be taken as read from the
interface: *anything* that is a javax.servlet.Filter is container
managed by design, whereas anything that is derived from an acegi
filter-like interface isn't.

Anyhoo, thats *way* more than enough for a first message... sorry if
I'm rehashing old discussions.

Cheers,
Baz

[1] http://www.athensams.net , the blurb: de facto standard for secure
access management for UK Education and Health sectors, holds 3 million
user accounts from over 2,000 organisations and controls access to 260
online services. I'm doing this for one of those services.

[2] http://opensource2.atlassian.com/projects/spring/browse/SEC-228
http://opensource2.atlassian.com/projects/spring/browse/SEC-229


---
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=lnkkid0944bid$1720dat1642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


Re: [Acegisecurity-developer] CAS configuration

2006-03-16 Thread Baz
Interesting. At first blush though, that attack relies on a messed up
virtual host setup, that doesn't 404 on an unrecognized host? I take
your point though, specifying it separately is bulletproof against
stupidity.

On 3/16/06, Scott Battaglia [EMAIL PROTECTED] wrote:
 Brian,

 There are specific reasons that CAS clients are not recommended to rely
 on the HttpServletRequest to retrieve the host name.

 This is documented here: http://www.ja-sig.org/wiki/display/CAS/CASFilter

 All Java clients distributed by Yale rely on providing either a hostname
 specifically, or the exact service URL.

 -Scott

 Scott Battaglia
 Application Developer, Architecture  Engineering Team
 Enterprise Systems and Services, Rutgers University
 v: 732.445.0097 | f: 732.445.5493 | [EMAIL PROTECTED]



 Baz wrote:
  Hi all,
  I've been implementing acegi integration with Eduserv Athens[1] and
  have been chatting to Luke about some oddities in the CAS integration
  (Athens and CAS are quite similar, so I was getting up to speed by
  browsing the code). A couple of these have been raised as bugs[2] but
  there's other bits I'd like to ask about.
 
  - is org.acegisecurity.ui.cas.ServiceProperties.get/setService() required?
  It seems to me that this duplicates configuration elsewhere, since it
  can only have the value that would be calculated by this method (if
  you add this to CasProcessingFilter):
  public String getService(HttpServletRequest request) {
  int serverPort = request.getServerPort();
  String scheme = request.getScheme();
  StringBuffer sb = new StringBuffer(scheme);
  sb.append(://);
  sb.append(request.getServerName());
  if (!(serverPort == 80  http.equalsIgnoreCase(scheme))
   !(serverPort == 443  
  https.equalsIgnoreCase(scheme))) {
  sb.append(:).append(serverPort);
  }
  sb.append(request.getContextPath());
  sb.append(getFilterProcessesUrl());
  return sb.toString();
  }
 
  (incidentally a similar fragment to this is duplicated throughout the
  acegi code, pretty much everywhere PortResolver is used?)
 
  In the current setup, you can't use this code because
  CasProxyTicketValidator.confirmTicketValid() doesn't get access to the
  request. However, it's only called from
  CasAuthenticationProvider.authenticateNow, which has access to
  WebAuthenticationDetails constructed from the request, so the filter
  can make this information available there?
 
  The other thing I wanted to ask about isn't specific to CAS. I'd
  extended AbstractProcessingFilter and implemented
  AuthenticationEntryPoint as separate classes, much the same as all the
  rest of the com.acegisecurity.ui packages. However I noticed that
  these both required the same config information, and simply making a
  single class that 'extends AbstractProcessingFilter implements
  AuthenticationEntryPoint' took the entry point down to 2 lines of
  code.
 
  Looking at the other ui packages, it seems that there is a similar 1:1
  correspondence between filters and entry points, with the duplicate
  config issue being handled in different ways (Basic+Digest auth
  delegates from the filter to the entry point, CAS uses
  ServiceProperties to factor out the common code)
 
  Looking at this, and the way that the 'Filter' classes aren't really
  (the lifecycle methods arent used, and they're all marked 'do not use
  directly') shouldn't all of these implement something like:
 
  public interface AuthenticationFilter { // not a javax.servlet.Filter
  // each filter is its own entry point.
  public void commence(ServletRequest request, ServletResponse response,
  AuthenticationException authException)
  throws IOException, ServletException;
  // the acegi filters are all http-only.
  void doFilter(HttpServletRequest request, HttpServletResponse
  servletResponse, javax.servlet.FilterChain filterChain) throws
  java.io.IOException, javax.servlet.ServletException;
  }
 
  I can that in the code sometimes things identical interfaces have been
  split for type safety (like AuthenticationEntryPoint and
  ChannelEntryPoint) but I can't see why this argument hasn't been
  applied to the Authentication Filters, since they can't be used as
  servlet filters.
 
  I've seen the 'servlet-container-managed' stuff in FilterToBeanProxy,
  but to me this looks like something that can be taken as read from the
  interface: *anything* that is a javax.servlet.Filter is container
  managed by design, whereas anything that is derived from an acegi
  filter-like interface isn't.
 
  Anyhoo, thats *way* more than enough for a first message... sorry if
  I'm rehashing old discussions.
 
  Cheers,
  Baz
 
  [1] http://www.athensams.net , the blurb: de facto standard for secure
  access management for UK Education and Health sectors, holds 3 million
  user accounts from over 2,000 organisations and controls access to 260
  online

[Acegisecurity-developer] Re: CAS configuration

2006-03-16 Thread Baz
On 3/16/06, Baz [EMAIL PROTECTED] wrote:
 Looking at this, and the way that the 'Filter' classes aren't really
 (the lifecycle methods arent used, and they're all marked 'do not use
 directly') shouldn't all of these implement something like:

must...think...before...hitting...send

ok clearly there are classes in there that don't want to implement
both doFilter() and commence(), like the RememberMe stuff. The
questions in the second half of my blather should really be:
- why not have CasProcessingFilter implement AuthenticationEntryPoint
and drop ServiceProperties? They can't be used separately.
- why is javax.servlet.Filter implemented throughout for things which
can't be used that way, while every other interface gets chopped up
for type safety?


---
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=lnkkid0944bid$1720dat1642
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer


Re: [Acegisecurity-developer] Securing using a pattern based on a mix of logical operators

2005-08-23 Thread Eric Ballet-Baz
Thanks for your reply !
I will investigate this point.
But I was unable and still am to find any reference in this forum to the same need.

Could someone give me some pointers ?
Thanks
Eric Ballet-Baz
On 8/22/05, Ben Alex [EMAIL PROTECTED] wrote:
Eric Ballet-Baz wrote: Allow access if : bar.foo.MyService.myMethod=ROLE_A AND (ROLE_B OR ROLE_C)
 Any idea ?Hi EricThere were some past discussions on implementation ideas in connectionwith this on the forums, so you might like to search there. In summarythere is no AccessDecisionManager that can do this at present. It
wouldn't be too hard to write one that looked like this:ROLE_A,,(ROLE_B||ROLE_C,)Notice the need to keep your configuration attributes comma-separated.This is because your AccessDecisionManager will still delegate to
AccessDecisionVoters for each individual configuration attribute.CheersBen---SF.Net email is Sponsored by the Better Software Conference  EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle PracticesAgile  Plan-Driven Development * Managing Projects  Teams * Testing  QASecurity * Process Improvement  Measurement * 
http://www.sqe.com/bsce5sf___Home: http://acegisecurity.sourceforge.netAcegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/acegisecurity-developer



[Acegisecurity-developer] Securing using a pattern based on a mix of logical operators

2005-08-22 Thread Eric Ballet-Baz
Hi everybody,

In my current application, I must implementa simple security pattern to secure my services, based on a mix oflogical operators AND and OR.
But I haven't found any solution so far, and what's surprise me the most is that I can't find any reference to a similar simple problem ...

I just want to have something like :

Allow access if :

bar.foo.MyService.myMethod=ROLE_A AND (ROLE_B OR ROLE_C)

Any idea ?

In fact in my case there is maybee a simple trick, becauseROLE_A is always the same value (something like APPLICATION_A wich every user allowed to access my application has).

Thanks
Eric Ballet-Baz