RE: [Acegisecurity-developer] checking for invalid user accounts in AuthenticationProvider implementations
Yes, I'm aware that certain providers might not have the right hooks for all the checks we do, but in our case we are using Jaas alongside with our own implementation of a Provider to create an custom UserDetails object, and rather than copy/paste the checks against UserDetails that are performed in the DaoAuthenticationProvider, I thought it would be put to better use by making that specific part of code accessible for other classes to use if needed. I will file a JIRA issue on it today. Thanks! -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger Sent: Saturday, March 25, 2006 8:51 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] checking for invalid user accounts in AuthenticationProvider implementations That isn't really possible for the JaasAuthenticationProvider without Jaas Provider specific hooks. The Jaas LoginModule interface doesn't provide isAccountNonLocked style accessors. On 3/25/06, Ben Alex [EMAIL PROTECTED] wrote: Tim Kettering wrote: Maybe it'd be useful if those checks found in DaoAuthenticationProvider be made available as a pluggable component that other AuthenticationProviders can utilize? Hi Tim If you please add it to JIRA, I'll make a static method that accepts a UserDetails and throws an appropriate AuthenticationException based on its state. Best regards 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 --- 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=kkid0944bid$1720dat1642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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] checking for invalid user accounts in AuthenticationProvider implementations
Hey all, Can someone (Ben?) explain if it is expected to check the various UserDetails states such as isAccountNonExpired(), isAccountNonLocked(), isCredentialsNonExpired(), and isEnabled() in a AuthenticationProvider? This seems to be applied inconsistently... We had originally been using DaoAuthenticationProvider, which in its code does those checks, then we switched over to the JaasAuthenticationProvider and after seeing some logins that occured that shouldn't have occured, I tracked down the issue to JaasAuthenticationProvider not doing those checks at all. Looking at CasAuthenticationProvider, this seems to not either. Maybe it'd be useful if those checks found in DaoAuthenticationProvider be made available as a pluggable component that other AuthenticationProviders can utilize? Thanks, -tim --- 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] using an embedded library that also uses acegi
Just wanted to put this out here, to see what the developers have to say about the implications of using a library that uses acegi internally, inside an application that also uses acegi. in our case, we're using 1.0 RC, while the library we're evaluating uses 0.8.2, and that already has brought up some classloading considerations, due to the different package names. And I'm also wondering what the effect will be on the security context in the thread. I don't believe there is any sort of name-spacing/sandboxing of diff security contexts, are there? Any feedback or thoughts would be greatly appreciated. -tim --- 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] setting attributes for remember-me cookie
Ben, I actually filed a JIRA issue on it yesterday, and submitted a patch: http://opensource.atlassian.com/projects/spring/browse/SEC-206 However, I had hoped to have some discussion on the list before submitting the patch because there was some questions about how defaults should be handled, and whether setting the path should be an property (or just implicitly set to root), or some mix of the two. The patch I submitted implicitly sets to root.. more details are in the jira issue and the patch itself. Hopefully it's useful. Feel free to discuss this further if you feel it needs to offer more flexibility. Thanks! -tim On 3/2/06, Ben Alex [EMAIL PROTECTED] wrote: Tim Kettering wrote: I scoured the forums and mailing list and did not find anyone bringing up this issue. I suspect it's because everyone (?) so far might have been using the filter based login. Which we are not, so this would not be a problem for them. Hi Tim If you are able to provide a JIRA patch that will provide this flexibility, I would be happy to apply it for you. 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 --- 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] setting attributes for remember-me cookie
Hi Everyone. Mabye there's already a really simple solution that's been staring me in the face but I'm not seeing it. I'm setting up the remember-me functionality for this project I'm working on, and due to project technical considerations, I've have to re-implement parts of the remember-me in the login controller instead of using the authentication filter. So basically what's happening is that on a successful login, the login controller will be making a call to the rememberMeServices.loginSuccess(), to set the remember-me cookie. But when I set out to test it, it didn't work. I dug around a bit and I think I found the problem, the application runs under the context /foo, and the login controller url is found at /foo/login, so the acegi remember-me cookie gets set with a path of /foo/login - which makes it fall out of scope when accessing /foo, if i understand the functionality of cookies right. So I've been looking at the code in acegi, and it seems like a Cookie is simply created with defaults in the TokenBasedRememberMeServices. So it would appear to me that I would need to subclass certain parts of this code to get it to set the path to something different than the default. I scoured the forums and mailing list and did not find anyone bringing up this issue. I suspect it's because everyone (?) so far might have been using the filter based login. Which we are not, so this would not be a problem for them. So, I thought I'd bring it up on the list.. see what you guys think should be done. -tim --- 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] Proposal: Rename AuthenticationDao interface
+1 from me too. I think its better to break stuff now when we still have a excuse (hey, it ain't 1.0 yet) than post 1.0. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger Sent: Thursday, November 17, 2005 10:01 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface lol Sorry Scott :) When Ben puts it like that I gotta agree hehe. +1 On 11/17/05, Dmitriy Kopylenko [EMAIL PROTECTED] wrote: +1 also Darrell Kundel wrote: +1 I support the change, it makes more sense to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Thursday, November 17, 2005 9:23 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface Ray Krueger wrote: You currently have an AuthenticationDao that successfully returns a UserDetails instance that is built up by your four database scheme now, correct? The whole point of the AuthenticationDao is to build a UserDetails instance, by whatever means necessary. So, no, users like you should do exactly what you're doing. I don't see a reason for you two implement a new AuthenticationProvider, unless the DaoAuthenticationProvider is not meeting you're needs. The one and only method defined by AuthenticationDao is: public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException; AuthenticationDao is used variously within the system: Implementation: JdbcDaoImpl Implementation: InMemoryDaoImpl User: DaoAuthenticationProvider User: DaoCasAuthoritiesPopulator User: DaoX509AuthoritiesPopulator User: DigestProcessingFilter User: TokenBasedRememberMeServices User: SwitchUserProcessingFilter AuthenticationDao is presently found in the org.acegisecurity.providers.dao package. Given only the first three classes above are actually in that package or a subpackage, perhaps AuthenticationDao should be moved to a higher-level package to reflect its broader use in five other areas of the framework. We faced a similar transition for UserDetails itself, from the DAO package to the top-level package for a similar reason. Whilst it's mostly semantics, the other side is clarifying relationships and scope of services within the framework. Perhaps we should rename org.acegisecurity.providers.dao.AuthenticationDao to org.acegisecurity.UserDetailsService. It will mean that most users have to make a fairly minor change to the interface they're implementing in their AuthenticationDao implementations, but aside from that it will be transparent. If we do this, it might even be better to make an org.acegisecurity.userdetails package, to hold UserDetails, User, UserDetailsService and the two implementations listed above. At least we'd be emphasising these classes can be used anywhere within the framework or by your code - not just for DaoAuthenticationProvider. Anyhow, I note the current responses consider this mostly a semantics issue, but I tend to see where Scott's coming from regarding clarifying architectural use and layering. We can make these moves with losing revision history (I feel game - I'll log another SF CVS job! :-) ). And users are already going to be *having* to change the import of their AuthenticationDao implementations anyway, due to the package rename in SEC-104. Thoughts? Cheers Ben --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28alloc_id845op=ick
[Acegisecurity-developer] AclVoter expecting SimpleAclEntry
I ran into a interesting problem when setting up AclVoters for our project.
We are using our own custom AclEntry that subclasses AbstractBasicAclEntry.
So when I tried to set up a class that uses AclVoter, I got a
ClassCastException at this particular section:
for(int i = 0; i entries.length; i++) {
SimpleAclEntry sae = (SimpleAclEntry)entries[i];
for(int j = 0; j requirePermission.length; j++) {
if(sae.isPermitted(requirePermission[j])) {
result = ACCESS_GRANTED;
}
}
}
So, from this, it seems that we are casting to SimpleAclEntry because we
need to access the method .isPermitted(). But this method is defined in
AbstractBasicAclEntry. However because it is abstract, we cannot cast to
that specifically...
So my subclass doesn't work, even though it has the method necessary to work
properly.
I think this can be improved... it just seems rather odd for BasicAclEntry
to not declare the method, but the abstract implementation does, and then
SimpleAclEntry makes use of it? This doesn't lend well to making AclVoter
very extensible.
I think could either add the methods to BasicAclEntry, or make another
interface to back the added functions that AbstractBasicAclEntry brings to
the table and update AclVoter accordingly.
Thanks!
-tim
---
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42 plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl
I took another look at the JdbcDaoImpl (and JdbcExtendedDaoImpl). I think I understand what I was missing before, and I have a suggestion to add as well. In JdbcDaoImpl, the default query strings are static string parameters. In the constructor of JdbcDaoImpl, the default strings are copied to the query string parameters that are called by the internal sql mapping classes, in their constructors. So if my understanding is correct, the object instance is created first, meaning the internal classes are initially created w/ the default strings, before any getter/setters are called by Spring. So what I was likely missing before was the need to set 'init-method=initDao' in the spring configuration to make sure that the initDao() method was called after spring was finished, to re-initialize the internal sql mapping objects after the new sql query strings are set by spring. So if this init method is not called, then attempting to use it will result in the class ignoring the set query strings, and using the default ones. So this should probably be explicitly documented in the JavaDoc that if you are setting the query strings, you need to call 'initDao()' as well. Or a different mechanism used to detect changes and remove the dependency on 'initDao'. The other thing I wanted to bring up, was that JdbcExtendedDaoImpl introduces a new method: String convertAclObjectIdentityToString(AclObjectIdentity aclObjectIdentity) Which converts the aclObjectIdentity argment to a string that it can use to query the database. If you look at JdbcDaoImpl, in the 'getAcls(AclObjectIdentity aclObjectIdentity)' method, you'll find that theres a section of code that does virtually the same thing. So I would think it'd be cleaner code-wise and consistency for the 'convertAclObjectIdentityToString' method to be moved to JdbcDaoImpl, and used to implement the conversion to string in 'getAcls' as well. This would also make it easier to extend the class and still invoke the superclass 'getAcls' when working with ACLs that need to be converted to different string formats than the standard used in Acegi. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Kettering Sent: Monday, August 22, 2005 6:42 PM To: acegisecurity-developer@lists.sourceforge.net Subject: RE: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl I believe it does not work if you extend the class itself, due to how the internal MappingSqlQuery classes that implement those queries set/reference themselves. Seems like the default strings get applied via constructor before the setter methods are called via spring. I am not 100% on this. It was a while ago, and I may have done something incorrectly. This kind of pertains to my earlier email about how I found it difficult to extend JdbcDaoImpl (and the extended Dao as well), in a clean fashion. If I have some time tomorrow, I can try to investigate this and report with more conclusive results. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Monday, August 22, 2005 6:11 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl Pascal Gehl wrote: Hi, I've written a blog entry on how to extend JdbcDaoImpl. I would appreciate guru's to check if I don't misunderstood it. http://www.jroller.com/page/paskos?entry=acegi_using_a_custom_select Hi Pascal You should have been able to use setAuthoritiesByUsernameQuery(String) and setUsersByUsernameQuery(String) on JdbcDaoImpl. Did that not work? Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005
RE: [Acegisecurity-developer] using long for acegi acl id parameters
Ben, Yes, sorry I wasn't clear on which class. I meant the AclDetailsHolder in the JdbcDaoImpl. I've been forced to fork off the JdbcDaoImpl code into my own classes completely here due to the fact that they're rather hard to extend if you want to do more than just tweak the query strings. One of the issues I ran into was that AclDetailsHolder and other internal classes make it difficult to extend because the code apparently still calls the original implementations, not my implementations, and there doesn't seem to be a clean way to hook into my own classes. Although I really have just started working on this stuff for a few days, and I would need to work with it some more to formulate some suggestions on how to make them more easily extensible. But changing the values to long would be a good start. I would submit a patch, but Sourceforge's CVS still is not working for me at the moment. I'll file a JIRA issue on it. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Sunday, August 21, 2005 6:14 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] using long for acegi acl id parameters Tim Kettering wrote: I'm wondering if there was a reason that most of Acegi's standard ACL classes use int when dealing with object id values. We usually default to using 'long' instead of 'int' - and I believe that other places do as well, so it seems to me that it might be simpler to use 'long' in the acegi classes, since the java compiler can automatically cast int to long anyway. Hi Tim Which ACL classes are you referring to? AbstractBasicAclEntry uses int because it performs bit masking which shouldn't need the full size of a long. If you mean AclDetailsHolder (protected class within JdbcDaoImpl) I see your point and we should change it. Please feel free to submit a patch or issue to JIRA and I'll get it done. Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] using long for acegi acl id parameters
Filed under JIRA as SEC-51. I also filed a issue a few days ago w/ a patch to fix something w/ acegi's JAAS handler (SEC-48). Would be nice if this could be added to CVS before the 0.9 release. Thanks! -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Kettering Sent: Monday, August 22, 2005 10:42 AM To: acegisecurity-developer@lists.sourceforge.net Subject: RE: [Acegisecurity-developer] using long for acegi acl id parameters Ben, Yes, sorry I wasn't clear on which class. I meant the AclDetailsHolder in the JdbcDaoImpl. I've been forced to fork off the JdbcDaoImpl code into my own classes completely here due to the fact that they're rather hard to extend if you want to do more than just tweak the query strings. One of the issues I ran into was that AclDetailsHolder and other internal classes make it difficult to extend because the code apparently still calls the original implementations, not my implementations, and there doesn't seem to be a clean way to hook into my own classes. Although I really have just started working on this stuff for a few days, and I would need to work with it some more to formulate some suggestions on how to make them more easily extensible. But changing the values to long would be a good start. I would submit a patch, but Sourceforge's CVS still is not working for me at the moment. I'll file a JIRA issue on it. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Sunday, August 21, 2005 6:14 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] using long for acegi acl id parameters Tim Kettering wrote: I'm wondering if there was a reason that most of Acegi's standard ACL classes use int when dealing with object id values. We usually default to using 'long' instead of 'int' - and I believe that other places do as well, so it seems to me that it might be simpler to use 'long' in the acegi classes, since the java compiler can automatically cast int to long anyway. Hi Tim Which ACL classes are you referring to? AbstractBasicAclEntry uses int because it performs bit masking which shouldn't need the full size of a long. If you mean AclDetailsHolder (protected class within JdbcDaoImpl) I see your point and we should change it. Please feel free to submit a patch or issue to JIRA and I'll get it done. Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl
I believe it does not work if you extend the class itself, due to how the internal MappingSqlQuery classes that implement those queries set/reference themselves. Seems like the default strings get applied via constructor before the setter methods are called via spring. I am not 100% on this. It was a while ago, and I may have done something incorrectly. This kind of pertains to my earlier email about how I found it difficult to extend JdbcDaoImpl (and the extended Dao as well), in a clean fashion. If I have some time tomorrow, I can try to investigate this and report with more conclusive results. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Monday, August 22, 2005 6:11 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Blog entry on how to extend JdbcDaoImpl Pascal Gehl wrote: Hi, I've written a blog entry on how to extend JdbcDaoImpl. I would appreciate guru's to check if I don't misunderstood it. http://www.jroller.com/page/paskos?entry=acegi_using_a_custom_select Hi Pascal You should have been able to use setAuthoritiesByUsernameQuery(String) and setUsersByUsernameQuery(String) on JdbcDaoImpl. Did that not work? Cheers Ben --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] using long for acegi acl id parameters
Im wondering if there was a reason that most of Acegis standard ACL classes use int when dealing with object id values. We usually default to using long instead of int and I believe that other places do as well, so it seems to me that it might be simpler to use long in the acegi classes, since the java compiler can automatically cast int to long anyway. Just my two cents. -tim
RE: [Acegisecurity-developer] cannot access cvs
Same here cannot access CVS since yesterday. I guess SF is messed up again. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 19, 2005 11:09 AM To: acegisecurity-developer@lists.sourceforge.net Subject: [Acegisecurity-developer] cannot access cvs Im getting an error Project map lookup failed both by doing manual cvs login and executing the maven checkout command that is shown of acegis site.
RE: [Acegisecurity-developer] logout functionality
Okay, allow me to take back what I said. I later realized that the user in session would have nothing to do with where the voters would be obtaining the user object from, so if I was properly removing the user from the SecurityContextHolder, then everything should be working right. So I went back and double checked my code, and turns out I was performing the logout operation in the Render phase, not Action, even though I was saying otherwise on my previous email. Now dont I look all foolish. J So, a big mea culpa and apologies to all. -tim From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Kettering Sent: Friday, July 22, 2005 1:58 PM To: acegisecurity-developer@lists.sourceforge.net Subject: [Acegisecurity-developer] logout functionality I was looking around for logout tips/practices on the forums, and I found this thread from a while ago http://forum.springframework.org/viewtopic.php?t=5407highlight=logout So, as I understand this, setting a new security context in 0.9 and up will effectively log out a user. The project Im working on, which is a bunch of portlets running under a portlet container. We are using Acegi to manage object-level permissions in the various portlets using ACL. Since the changes to the user are not written back to the session until the end of the request the changes do not take effect for that initial request. On a standard webapp, this would normally not be an issue because the page could easily forward to a logout page or something, and then all future requests would be processed as usual. However, with portlets, since we have Portlet A, Portlet B, and Portlet C and a Login/Logout Portlet all existing on one page, it works differently. When I click the logout link on the login/logout portlet, the user is indeed logged out, but since the user still exists in session, Portlets A, B and C still render their views as if the user was still logged in. It is not until the next web request (or a page reload) that the views are updated correctly. I believe this occurs because of the two phase process (Action then Render) process. The logout is executed in the Action phase, then all Portlets are rendered, but because the user is not removed from session until end of request, the Render phase still has the User in session visible, and acts accordingly so. So from a user/developer point of view on the web page, the user has logged out, but the data that is displayed in portlets are still displaying as if the user was logged in. As more people start using Spring, and Acegi to build portlet applications, I am quite certain this will become a common issue. I plan to resolve this issue for the short term by explicitly clearing the ACEGI context from the session in the Action phase. I do think that there should be some re-consideration for a unified (or at least an endorsed) strategy for clearing the user on logout from both the context and the session. My understand of Acegi is still rather new Im learning this stuff as I go, so if I have made any misassumptions, feel free to correct me. I thought itd be a good time to bring this up for discussion w/ the devs. -tim
[Acegisecurity-developer] behavior of JaasNameCallbackHander
I was tracking down some issues that came up after we
started using our own UserDetails object in the principal of Authentication.
This method in JaasNameCallbackHandler seems to be calling the incorrect
method. In AbstractAuthenticationHandler, the methods called are authentication.getPrincipal().getUsername()
not toString() like it appears below. Is there any reason for
this? The problem we are facing is that our JAAS handler is trying to
authenticate on the entire toString() output of our UserDetails object, instead
of just the username, at this point, when the Acegi API/source seems to
indicate that toString() is to be used for debug output.
public void handle(Callback callback, Authentication
authentication)
throws IOException, UnsupportedCallbackException {
if (callback instanceof NameCallback) {
NameCallback ncb = (NameCallback) callback;
ncb.setName(authentication.getPrincipal().toString());
}
}
RE: [Acegisecurity-developer] Suggested approach for authority design
Ray,
Many thanks for writing in. You've pretty much confirmed many of the things I
was thinking. I just wanted to be sure that I was going down the path of least
resistance and not run across some DOH! Moment a month later when I realize
there's a far better way to do it.
I think what I'll do is create a custom AuthorityProvider that will do the jaas
operations and the role creation I need, since there are other stuff I should
be pulling in as well that are not coming from JAAS, and using an
AuthorityGranter doesn’t sit well with me.
Thanks again for your input. Appreciate it much.
-tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger
Sent: Monday, July 18, 2005 11:44 PM
To: acegisecurity-developer@lists.sourceforge.net
Subject: Re: [Acegisecurity-developer] Suggested approach for authority design
Hey Tim, Jaas is full of smells :P
Let's see if I can help you out here...
1. You are correct. You can chain AuthenticationProviders, but as soon
as one returns a valid token the chain ends.
2. The first part of this is what the AuthorityGranter interface is
designed for. The AuthenticationDao thing, I'm not sure what your
intent was. Either way, the AuthenticationDao.authenticate(...) method
returns a UserDetails instance, which has the GrantedAuthority[]
getAuthorites() method on it.
3. The AuthorityGranter (AuthorityResolver would have been a better
name though hehe) returns a set for exactly the reason you mentioned.
You pass it a principal and it returns a set of ROLE_names. This +
some jdbc access or whatever your authority source is going to be
would be an option. Inelegance is in the eye of the beholder :P
One thing to keep in mind with Jaas, there will (almost) always be at
least one principal to work with, and that's the user. So if certain
users are going to get extra roles or authorities based on their
username for example writing an AuthorityGranter to do that would be
the way to go.
I hope this helps, or at least made sense.
-Ray
On 7/18/05, Tim Kettering [EMAIL PROTECTED] wrote:
Hi everyone,
On this project I'm working on, we are using JAAS to authenticate a token,
and Acegi's JAAS support classes allow for the translation of the user and
its principals to Acegi's authority objects. But in this particular case,
we are not interested in the principals that JAAS returns. We want to
continue using our own method for obtaining the authorities.
So I've been looking at a few possible approaches. But none of them seem to
really avoid the sense of code smell, so I thought I'd ask on the list for
suggestions from people who may be more familiar with a better strategy.
using a different authentication provider to simply populate the authorities
– it seems to me that authentication manager will only process with one
authentication provider, and if it returns a valid token, it does not
continue down the list… so when jaas authentication provider returns a valid
token, it wont process the custom class I made. (correct me if im wrong).
Replace Acegi's JaasAuthenticationProvider with a similar one of our own
that adds a method that obtains the additional authorities and adds it in.
This was the approach I started with, and I thought perhaps I could make use
of the AuthenticationDao to obtain the authorities I needed for the user and
add them in, but apparently AuthenticationDao does not provide an easy way
to simply obtain the authorities.. but instead, need to obtain the user
itself.
With the latest code in HEAD, AuthorityResolver can now return a set, so I
could hack a custom Resolver that ignored the returned Jaas Principal and
simply provided its own, but this seems rather inelegant, and has it's own
issues.
So, I guess I'm asking here.. is there a easier way (that I've missed) to
introduce my own GrantedAuthorities in the JAAS authentication flow??
Thanks in advance!
-tim
HS^µéšŠX¬²š'²ŠÞu¼ƒŠÇ(½êÄjÌ‹Š{±2(+jب+kj×
‰ë®‰ˆÁbÛš™^¶‡è–Z0F†™ªl²ÚÚŠm~Šðj·Z®Øœ•ëú+™«b½åžmƬ¶Æ§vj+xgz÷«ÊØbž
¨ºwžvÚ zÛ©¶‹)yç_jËa¶Úý§l¢Çgr‰¿iؾ;í©e¡È^¸÷j)ÉbrAè™èm¶ŸÿiÇ [EMAIL
PROTECTED]±ç.®+ruëÞ–Š^®f¢–)à–+-Ç
ŠÇœº¸ÉׯzZ)z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.ÇŸ¢¸ ë–+-³ùb²Ø§~Úqè±ç.®+ruëÞ–Š^
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Suggested approach for authority design
Hi everyone, On this project Im working on, we are using JAAS to authenticate a token, and Acegis JAAS support classes allow for the translation of the user and its principals to Acegis authority objects. But in this particular case, we are not interested in the principals that JAAS returns. We want to continue using our own method for obtaining the authorities. So Ive been looking at a few possible approaches. But none of them seem to really avoid the sense of code smell, so I thought Id ask on the list for suggestions from people who may be more familiar with a better strategy. using a different authentication provider to simply populate the authorities it seems to me that authentication manager will only process with one authentication provider, and if it returns a valid token, it does not continue down the list so when jaas authentication provider returns a valid token, it wont process the custom class I made. (correct me if im wrong). Replace Acegis JaasAuthenticationProvider with a similar one of our own that adds a method that obtains the additional authorities and adds it in. This was the approach I started with, and I thought perhaps I could make use of the AuthenticationDao to obtain the authorities I needed for the user and add them in, but apparently AuthenticationDao does not provide an easy way to simply obtain the authorities.. but instead, need to obtain the user itself. With the latest code in HEAD, AuthorityResolver can now return a set, so I could hack a custom Resolver that ignored the returned Jaas Principal and simply provided its own, but this seems rather inelegant, and has its own issues. So, I guess Im asking here.. is there a easier way (that Ive missed) to introduce my own GrantedAuthorities in the JAAS authentication flow?? Thanks in advance! -tim
Re: [Acegisecurity-developer] New features now in CVS
Hi Ben, Its funny how things like this work out, because I was just pondering a design issue on friday, and over the weekend, I thought I should probably email the acegi list about this, and then I read this email and it seems that you've already provided part, if not the whole solution. In my project, I am incorporating the use of acegi security, and making specific use of the ACL for checking permissions of the user against the objects. I've gotten it working w/ doing checks on single items, like for instance, loading a single object from the data source, and allowing/rejecting the method invocation, but my next problem is when the method could potentially return more than one object. Like say, if I made a method call to return all items in the database between dates A and B. I would need to run the security check on the collection after the data load to ensure that only the allowed objects are loaded. So, this new afterinvocation provider you wrote up will help me with this situation? -tim On Nov 14, 2004, at 10:38 PM, Ben Alex wrote: Hi everyone I've just committed a (potentially very useful) new feature to Acegi Security. After secure object invocation allows you to throw an AccessDeniedException or modify the Object returned from your secure object invocation. There's a new package, net.sf.acegisecurity.afterinvocation, which contains a couple of related providers. Both use AclManager and the integer bit masking provided by net.sf.acegisecurity.acl.basic. One of the providers throws an AccessDeniedException if the Authentication doesn't have an ACL permission for the returned Object (the required permission is defined in the application context). The other provider removes any item from a Collection if the Authentication doesn't have an ACL permission for that particular Collection element (again, the required permission is defined in the application context). To help with before invocation ACL security, there's also a new AccessDecisionVoter called BasicAclEntryVoter. It votes to deny access if the Authentication doesn't have an ACL permission for a given method argument (the class type of the method argument, the permission required etc are application context defined). The above isn't documented yet, but the Contacts sample application has been extensively refactored to use the above. Contacts are no longer owned by a single principal, but there is an ACL for each Contact. Permissions used include administer, delete and read. If the administer permission is held, the principal can modify the permissions list, adding or deleting ACL entries. I'd be interested in what people think of these changes. In particular, please give Contacts a try and report any bugs to the list. To build it you'll need to CVS checkout, then from core do a maven jar:install, then from samples/contact do a maven war. Best regards Ben --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] (no subject)
Yes, that would work. Thanks.
-tim
Hi Tim
Yes, the design does require the DAO provider know how to interpret
the presented AclObjectIdentity.
As you know, JdbcDaoImpl (and any BasicAclDao for that matter) needs
to be able to create BasicAclEntry[]s in response to the DAO request.
Each BasicAclEntry has getAclObjectIdentity() and
getAclObjectParentIdentity() methods, meaning the BasicAclDao needs to
convert from row-data expressing this information into a new object
instance. So, whilst your proposal caters for object - database
mapping, it doesn't address database - object mapping.
I guess we could offer a pluggable interface within JdbcDaoImpl which
does this conversion. ie:
public interface AclObjectIdentityStringResolver {
public AclObjectIdentity convertToIdentityObject(String identity);
public String convertToIdentityString(AclObjectIdentity
aclObjectIdentity);
}
Would that address your needs?
Ben
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] problem with using ehcache in junit tests
Hi all, I was tracking down an issue earlier today regarding running some junit tests against my code. Basically I was doing some simple benchmarks on the user authentication provider, and I decided to throw in the ehcache configuration in the spring context and thats when it all blew up - the authentication provider (DaoAuthenticationProvider) was throwing a NPE - a quick look in the debugger showed me that the cache instance in the provider was null, which should have been impossible because the bean postProcess method explictly checks for a null cache instance. looking thru the process in the debugger, it seems like junit creates a new instance of every test method, so if I inititalize the spring context in the junit test constructor, and then run 3 test methods, junit will initalize the spring context three times and run each test method in sequence. so trying out something, I disabled all but one test method, and ran the test. The test ran fine, and ecache worked correctly, but as soon as I enabled a second (or more) test methods, the test would fail on the ecache access. So I think there's some sort of issue going on here with multiple spring contexts being instanced, but a shared ecache instance exists in the JVM - so possibly after the first unit test method runs, the cache is set to null, and the second test method gets tripped up over an null cache instance that it wasn't expecting or something. I'm not sure if this is an intended effect of ecache, or what. So I thought I'd report my findings to the list. -tim --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] problem with using ehcache in junit tests
Nevermind. I just checked CVS and there's already a fix in there, post 0.6 release for this. I'll just go back to the corner where I came from. -tim On Aug 24, 2004, at 3:37 PM, Tim Kettering wrote: Hi all, I was tracking down an issue earlier today regarding running some junit tests against my code. Basically I was doing some simple benchmarks on the user authentication provider, and I decided to throw in the ehcache configuration in the spring context and thats when it all blew up - the authentication provider (DaoAuthenticationProvider) was throwing a NPE - a quick look in the debugger showed me that the cache instance in the provider was null, which should have been impossible because the bean postProcess method explictly checks for a null cache instance. looking thru the process in the debugger, it seems like junit creates a new instance of every test method, so if I inititalize the spring context in the junit test constructor, and then run 3 test methods, junit will initalize the spring context three times and run each test method in sequence. so trying out something, I disabled all but one test method, and ran the test. The test ran fine, and ecache worked correctly, but as soon as I enabled a second (or more) test methods, the test would fail on the ecache access. So I think there's some sort of issue going on here with multiple spring contexts being instanced, but a shared ecache instance exists in the JVM - so possibly after the first unit test method runs, the cache is set to null, and the second test method gets tripped up over an null cache instance that it wasn't expecting or something. I'm not sure if this is an intended effect of ecache, or what. So I thought I'd report my findings to the list. -tim --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] (no subject)
Thought about posting this in the forum, but thought the dev mailing list would be a better place to bring this up. I've gotten my prototype to successfully perform ACL authentication at the method invocation level. So right now I'm going a bit further beyond the standard ACL implementation given by Acegi to make it fit our needs. One issue I've run into now when Im attempting to use my own AclObjectIdentity. Because while I can set AclManager to use a specific class of AclObjectIdentity, the JdbcDaoImpl implemenation of BasicAclDao specifically checks for AclObjectIdentity to be of NamedEntityObjectIdentity. So basically any attempt to check ACLs on a custom AclObjectidentity will not work w/ jdbcDaoImpl. I see from the code that its necessary to do this because it needs to get values from getId() and getClassname(), which are not part of the interface signature of AclObjectIdentity to create the sql string. However, I would think that any sort of string returned by AclObjectIdentity would work. So I'm wondering if there's a better way this can be handled, like adding a extended interface of AclObjectIdentity that would be called BasicAclObjectIdentity and it would have an additional method such as getNamedEntityString() or something ilke that. And then people could create their own custom implemenations that would return String. Then the JdbcDaoImpl coudl check to ensure that the object passed in implements BasicAclObjectIdentity, instaed of a specific class implementation, which is really not what the Spring people advocate (code against interfaces, not classes). Re-coding the NamedEntityObjectIdentity to use the extended interface, and returning the string to be used in the SQL w/ the interface method would ensure that it would continue working, i think. If I'm missing something - then please do point out what it is. (I realize I can write my own custom DAO implementations to handle this stuff, but would like to extend/use as much acegi-provided code as possible. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
