can somebody explain the architecture for me? It looks great, and I want to know much deeper especially how the security managed by Acegi
Printable View
can somebody explain the architecture for me? It looks great, and I want to know much deeper especially how the security managed by Acegi
Acegi is involved in HISPACTA with its 2 main concerns:
1) authentication = user's login into the system. Tapestry pages are protected using PageValidationListener and when logged user is required it redirects him to LoginPage where Acegi login form is present (form action="j_acegi_security_check" with fields j_username and j_password)
When this form is submited, appropriate Acegi filters in cooperation with provided AuthenticationDao verify the credentials and if it is Ok a user object returned from the DAO is stored into HTTP session (in our case) and placed into "secure context" each time. Secure context is bound to the current thread of excecution (ThreadLocal used), so it can be accessed (using static method of ContextHolder class) by any piece of code (method) without the need to pass it through method arguments
2) authorization = verification if the logged user has the right to do something = to call particular service method
HISPACTA is here using Acegi's declarative authorization features. In our application context we define which roles or other conditions (verified by voters) are necessary to give access to this method. When the user doesn't meet the condition an AccessDeniedException is thrown. Our GUI also needs to know if the user have the right to do particular action (to display edit buttons or not). For this purpose a "query" methods are introduced like canModifyXYZ(). Those methods simply returns true, but the same security constraints are applied to them as to the "perform" methods. So this query methods returns true or throws AccessDenied exception.
The principles are well explained in Acegi reference docs.
Advantages?
* we have access to the current user object in any method of our code (no need to pass it as argument)
* the authorization rules are completely separated from business logic
* GUI calls only service methods, so it is completely independent of concrete Acegi implementation
* Tapestry pages can access the user object from Visit.getUser (where it is obtained from secure context)
* the service methods are always protected (not only when used with Tapestry GUI)
Feel free to ask any additional questions, I will build on top of them when creating some HISPACTA docs.
Regards,
Karel