Thanks Alex.
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.
Exactly, I think since i have been working on
spring-richclient for some time so feel comfortable in
terms of enabling\disabling commands or
creating\updating views depening on User's Role.
Also as you had mentioned Keith, Jim, Ollie and rest
of the forum are just as helpfull as you guys are here
on Acegi that I feel confident that I will always the
support to acheive my goals.
Regards
Amad
--- Ben Alex [EMAIL PROTECTED] wrote:
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=5588alloc_id=12065op=click
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
---
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=5588alloc_id=12065op=click
___
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
