Re: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release
Ben Alex wrote: For the small minority of people who have chosen NOT to extend User (which goes against our recommendations, but there are legitimate scenarios such as having a domain object that already represents the user), I don't think adding two methods to their implementation is going to cause much concern - especially as they can simply return false. I have just written the two additional exceptions, events, DaoAuthenticationProvider integration and PasswordDaoAuthenticationProvider integration. I deprecated the old User constructor. It's now all in CVS HEAD. Best regards Ben --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ 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] Roadmap towards Aceg Security official 1.0.0 release
Ben,
Finally I have jaas CredentialsExpiredException and
AccountExpiredException working under acegi security integrated in JBoss
container.
The modifications on acegi were quite simple.
First I have created 2 new Exceptions named:
net.sf.acegisecurity.AccountExpiredException
net.sf.acegisecurity.CredentialsExpiredException
I have also added 2 new container events
net.sf.acegisecurity.providers.dao.event.AccountExpiredEvent
net.sf.acegisecurity.providers.dao.event.CredentialExpiredEvent
And have added a new interface
net.sf.acegisecurity.ExpirationDetails
Which defines 2 methods isAccountExpired and isCredentialExpired
This interface is to be implemented by the same class that implements
UserDetails so that they can set appropriate values on these 2 methods.
Finally I have modified DaoAuthenticationProvider adding the following
lines
//account expiration check
if(ExpirationDetails.class.isAssignableFrom(user.getClass())){
ExpirationDetails expirationDetails=(ExpirationDetails)user;
if(expirationDetails.isAccountExpired()){
context.publishEvent(new AccountExpiredEvent(
authentication, user));
throw new AccountExpiredException(The provided login
account has expired);
}
if(expirationDetails.isCredentialExpired()){
context.publishEvent(new CredentialExpiredEvent(
authentication, user));
throw new CredentialExpiredException(The provided login
credential has expired);
}
}
I have added ExpirationDetails as a separate interface to keep backwards
compatibility with existing code that implementes UserDetails.
Finally I have modified JBossAcegiLoginModule so that it captures the new
exceptions and transforms them into the jaas corresponding exceptions.
} catch(CredentialExpiredException cee){
if (super.log.isDebugEnabled()) {
super.log.debug(Credential has expired);
}
throw new
javax.security.auth.login.CredentialExpiredException(The credential used
to identify the user has expired);
}catch(AccountExpiredException cee){
if (super.log.isDebugEnabled()) {
super.log.debug(Account has expired, throwing jaas
exception);
}
throw new javax.security.auth.login.AccountExpiredException(The
account specified in login has expired);
}catch (AuthenticationException failed) {
The main problem I have had is that JBoss on version 3.2.6 and 4.0 hid the
real exception and threw a general SecurityException ignoring the cause.
This has also been fixed by them on version 3.2.7 and next release of 4.0
as Scott confirmed.
So now the only thing left is to provide a test case and documentation. Do
you have any more comments or suggestions before I send you the final
code?
Sergio.
smime.p7s
Description: S/MIME cryptographic signature
RE: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release
Ben, What do you mean by container integration deprecation? Does it mean that the adapters package will dissapear in a next future or do you plan to move them to a sort of components sandbox? Sergio. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Ben Alex Enviado el: jueves, 30 de diciembre de 2004 2:53 Para: acegisecurity-developer@lists.sourceforge.net CC: [EMAIL PROTECTED] Asunto: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release Scott McCrory wrote: Ben, Just curious - what's your approach towards an eventual 1.0 release? I ask because technical managers, architecture review boards, etc. can misinterpret sub-1.0 versions as unstable, whereas even Acegi 0.6 most certainly is not! Thanks in advance, Scott Version 0.7.0 introduces the final features that I believe are necessary for a broadly useful enterprise application security framework. I believe most of the code could now be considered mature, except for the newer domain object instance security capabilities. Whilst these new capabilities have only existed for between two and four months, they're potentially HIGHLY useful, well-documented, fully unit tested, and demonstrated in the Contacts sample application. I also know of several real applications where they're being used, so I expect the API to remain fairly stable. By releasing Version 0.7.0 I hope to see the domain object instance security achieve more widespread use, so there can be appropriate confidence in a 1.0.0 release. To a lesser extent it is also intended to test the various new minor features added to CVS over the past few months, along with the Mavenised build system. I do not intend to add any new major features prior to a 1.0.0 release. There are several potentially useful areas, but none are critical for most applications and the architecture enables them to be added very easily and safely: * Remember-me functionality. There has been some design ideas put forward, but just not implemented. * Anonymous user functionality. This should be similar to any remember-me approach. People have already implemented solutions to this requirement (see forums). * Maintained and unit tested LDAP provider. There is something in the sandbox and contributions on the forums, but we need tests to add any to core. * Wider support for remoting protocol automatic security propagation. We already offer RMI and HttpInvoker, which covers most Spring Rich users. * Database-sourced ObjectDefinitionSources. Spring itself will be offering database-driven configuration (see sandbox). * Java 5 annotation support. I am waiting to see what happens with Spring core's attributes abstraction, and then use whatever approach follows. * AspectWerks support for domain object instance security. It's easy to do this, but I'd like a similar model to AspectJ where Spring DIs the advice. One issue I'd appreciate some comments on is container adapter deprecation. I know some people use the JBoss container adapter (as they need to use EJB security as well), but I've not heard of any usage of the Resin, Tomcat or Jetty adapters. It seems unwise to maintain a suboptimal (non-portable) approach, especially as pre-1.0.0 we can deprecate them. Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? Best regards Ben --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.6 - Release Date: 28/12/2004 smime.p7s Description: S/MIME cryptographic signature
Re: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release
Ben, Excellent, sounds like a well thought-out plan towards 1.0. I'd recommend an in-between approach for the container adapters. I agree that including lightly-used, non-portable modules in the main distribution can lead to expectations that they be maintained as fully as the core. However, there is potentially a lot of value in having them available with documentation and samples, and you never know which of them may become heavily used over the next year. As you already know, app security is a big problem space that Acegi helps a lot with, but everyone historically has taken different approaches to the problem so there's a lot to think through when incorporating Acegi into their project (add to that Spring IoC/DI - something new to most developers). The good thing is that container adapters, documentation and samples can help a lot with the initial learning curve since it helps the developer get a working prototype up and running faster in the environment they need to operate in, and I'd posit that there will be a handful of popular ones to boil out over 2005, probably including Siteminder (but that may just be my own environment talking). So what's a middle-ground? Perhaps keep them in the same project, but distribute them out into separate, optional JARs, a la Hibernate-Tools and document them in addendums of the main reference, and then clarify that these are platform-dependant without official owners, so they aren't considered part of the core product. Not a bad idea to try to pin an owner on each one nonetheless... Just thinking out loud - take or discard as you wish...! Scott On Thu, 30 Dec 2004 12:53:04 +1100, Ben Alex wrote Version 0.7.0 introduces the final features that I believe are necessary for a broadly useful enterprise application security framework. I believe most of the code could now be considered mature, except for the newer domain object instance security capabilities. Whilst these new capabilities have only existed for between two and four months, they're potentially HIGHLY useful, well-documented, fully unit tested, and demonstrated in the Contacts sample application. I also know of several real applications where they're being used, so I expect the API to remain fairly stable. By releasing Version 0.7.0 I hope to see the domain object instance security achieve more widespread use, so there can be appropriate confidence in a 1.0.0 release. To a lesser extent it is also intended to test the various new minor features added to CVS over the past few months, along with the Mavenised build system. I do not intend to add any new major features prior to a 1.0.0 release. There are several potentially useful areas, but none are critical for most applications and the architecture enables them to be added very easily and safely: * Remember-me functionality. There has been some design ideas put forward, but just not implemented. * Anonymous user functionality. This should be similar to any remember-me approach. People have already implemented solutions to this requirement (see forums). * Maintained and unit tested LDAP provider. There is something in the sandbox and contributions on the forums, but we need tests to add any to core. * Wider support for remoting protocol automatic security propagation. We already offer RMI and HttpInvoker, which covers most Spring Rich users. * Database- sourced ObjectDefinitionSources. Spring itself will be offering database-driven configuration (see sandbox). * Java 5 annotation support. I am waiting to see what happens with Spring core's attributes abstraction, and then use whatever approach follows. * AspectWerks support for domain object instance security. It's easy to do this, but I'd like a similar model to AspectJ where Spring DIs the advice. One issue I'd appreciate some comments on is container adapter deprecation. I know some people use the JBoss container adapter (as they need to use EJB security as well), but I've not heard of any usage of the Resin, Tomcat or Jetty adapters. It seems unwise to maintain a suboptimal (non-portable) approach, especially as pre- 1.0.0 we can deprecate them. Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? Best regards Ben --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list
Re: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release
Sergio Berna wrote: I have added ExpirationDetails as a separate interface to keep backwards compatibility with existing code that implementes UserDetails. Hi Sergio Good to see backward compatibility is a priority, particular in such a sensitive (ie commonly-deployed and extended) area as DaoAuthenticationProvider and UserDetails. I am just wondering whether it would be simpler, though, to modify the UserDetails interface so it contains the isAccountExpired() and isCredentialsExpired() methods? Then the existing constructor of the User implementation - which is what most people use - could set the properties to false. There would also be an additional constructor which AuthenticationDaos could use if they had access to the additional properties. We should probably also deprecate the existing constructor, to prompt people to consider the change (and move the decision to set the properties to a false default into their AuthenticationDao construction of User). For the small minority of people who have chosen NOT to extend User (which goes against our recommendations, but there are legitimate scenarios such as having a domain object that already represents the user), I don't think adding two methods to their implementation is going to cause much concern - especially as they can simply return false. This alternative would still provide 95% of users with full backwards compatibility, but avoid an extra interface. As the project also provides basic implementations of each interface, it also avoids us needing to write a UserExpirationDetails (for example). It is also cleaner to avoid these extra classes given that people often cast the contents of ((SecureContext)ContextHolder.getContext()).getAuthentication().getPrincipal(). It also makes these new properties and exceptions non-optional concepts in the overall framework, which means we will modify the included AuthenticationDaos (eg in-memory and JDBC), as well as the exception resolvers, to accommodate them. One other thing is the method names. I think it would be better to keep true being consistently returned as the affirmative/positive indication from each isX() method on UserDetails (there is already UserDetails.isEnabled()). So perhaps rename the methods to isCredentialsNonExpired() and isAccountNonExpired(), or something similar. Best regards Ben --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
