Hi,
Has
anyone tried to integrate the propriety Netegrity SiteMinder single sign
on ( http://www.netegrity.com/products/products.cfm?page=SMoverview
) with Acegi security.
If so
, any pointers on how to implement this would be appreciated.
Thanks
Shishir
Wouter,
Thanks for sending the example
solution.
I have finaly decided to remove the
AuthenticationChannelProcessor from Hispacta and replaced it by the standard
Tapestry way of page protection - PageValidateListener. It is not declarative,
but it seems to be simpler, more secure (doesn't
It looks to me like the authz tag does not work properly inside a
Sitemesh decorator, but works correctly if used inside an actual
decorated jsp. I suspect that there are some problems with the
ContextHolder ThreadLocal instance and the Sitemesh decorator not
playing well together, but I wante
I agree with your assessment Ben. Had many of those thoughts myself as
I was pondering our situation. In the end we went with VOTERS DETECT
OBJECT AS PARAMETER AND QUERY ACL OBJECT. Seems like the best choice
for us since we only want to deny or allow access not mutate or filter
properties of th
Wesley Hall wrote:
This would actually be my preference too. I dont think the stack trace will
be affected unless a new exception is created, but I would have liked to set
the Authentication object in an overloaded constructor. The problem is that
it seemed that in some cases the Authenication inst
Andy Depue wrote:
Has any thought been given to adding instance based security support to Acegi?
This seems to be a common requirement.
There are so many ways of approaching instant-level security, as touched
on by the other replies to this thread. The major issues are "where to
get the dom
Ben,
Comments below...
> >
> I've committed this one, minus the UsernameNotFoundException (because it
> gets re-thrown by DaoAuthenticationProvider in a BadCredentialsException).
>
> If people need to support additional application-specific (rather than
> Acegi Security-specific) exceptions, we c
This is exactly what I am implementing
right now. Funny, that this is the first post I see when I joined the list. I
am creating a series of custom voters:
·
SimpleRoleVoter – will grant
access if the user has the role in question, deny otherwise
·
EntityRoleVoter – will g
Actually, that is exactly what I was stating. He needs to know whether an
employee is a CEO or a regular employee since both use the same Employee object.
What I was eluding to is that currently, even if you added a property in the
Employee object to determine if it is a CEO or not, I was no
This is something I've been pondering
as well.
Stefan: I don't think that's what Andy
means. I believe that the security would be based on some property of the
instance, rather than of the user.
I came from the Notes/Domino world,
where a similar concept was applied with Readers and Authors pro
Can't this be done such using Method Security MethodInvocation
security in Acegi? Not sure how you know it is a CEO employee declaratively
though. I guess this is what you are asking.
like:
sample.Employee.getSalary=ROLE_MANAGER
sample.Employee.getAddress=ROLE_ALL
Sorry, I know the example
Has any thought been given to adding instance based security support to Acegi?
This seems to be a common requirement. Basically, what I mean by this is
that you can apply security constraints (hopefully in a declarative fashion)
to an object class with rules that are capable of discriminating
That's a good question.
1) I think it can be done on Tapestry
page level using PageValidationListener.
2) It should be possible to improve the
AuthenticationChannelProcessor to support ROLE_*
attributes.
--
I have also just discovered a security hole
with the URL patterns used
Hi Wouter,
I'm using Channel Processing Filter to protect
the pages which requires user authentication (instead of commonly used HTTP
Request Security Filter), because of the different approch used by Tapestry to
access its pages. This Channel Processing Filter is commonly used for
restric
14 matches
Mail list logo
