Amad Fida wrote:
Thanks Alex,
just ignore my last email as you have explained in
detail what I need to do in order to get going with
Acegi.
The problem with #2 in my case is I don't know which
SSO solution each implementtion will require. It can
be SiteMinder, IBM's TAM or any other implementation.
Given CAS is already implemented, you should be fairly confident Acegi
Security will work for you. Colin mentioned JOSSO (Java Open Single
Sign-On) last week. You could have a go at implementing that if you
wish. If you need a hand implementing another open source SSO solution,
just send a message to the list and I'll give you a hand. With two SSO
implementations you should be very comfortable the architecture is
flexible enough to support future SSO implementations. Of course if you
already have access to SiteMinder or one of the SSO implementations
you'll definitely need to support, that would be the one to implement!
Also I need to provide a default
AuthenticationProvider for cases where there is not
SSO solution. The default implementation will be
probably JDBC based.
I think you'll find the DaoAuthenticationProvider will work fine for you
as the fallback. Even with SSO implementations, typically you will
delegate to an AuthenticationDao anyhow to obtain the list of
GrantedAuthority[]s. SSO implementations typically focus on
authentication - they leave the application to worry about authorisation
and the roles/authorities granted to the authenticated user. As such
you'll probably use an AuthenticationDao with most/all SSO
implementations. As this is your common point, the AuthenticationDao's
responsibility for GrantedAuthority[] generation will provide
consistency that eases the concern you mentioned below.
so #2 also makes #3 little chalanging. But I am sure
with the help of this forum I can come up with a
solution which will be flexable enough to meet our
requirements.
I would encourage you to look at #5 if you are intending on
enabling/disabling actions in Spring Rich based on GrantedAuthority[]s.
It is something that strikes me as higher risk than the rest. Having
said that, it's just higher risk from my point of view as I'm far less
familiar with Spring Rich code than I am with Acegi Security code.
You'll probably find Spring Rich will accommodate what you need to do
just fine, and if not Keith Donald and the guys are very helpful.
Ben
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
