Wednesday, March 22, 2006

 

[RFE]Regex Capturing In Policies - Nice to Have!

OK, so COREid supports rudimentary pattern matching in policy patterns. For instance, one can create a URL pattern in a policy definition that matches multiple URLs with a single policy (pattern). The following URL pattern matches the three separate set of subdirectories.

/applications/{app1,app2,app3}/.../*

This allows a company to set up a single policy for multiple resources that are not identical but have the same access rules. This can help to stem mass profilferation of policies in the system. Many policies can make it more difficult to administer a system. As well, the more policies that exist in a system the longer it can take COREid to evaluate which policy or policy domain matches a particular request as policies are always evaluated first.

This is great functionality, but it could be a lot more powerful with additional regular expression capabilities. I am not advocating dumping the way current pattern matching works to replace it with a veriosn of the full blown regular expression language many have come to rely upon. I expect features such as look ahead could have potentially disasterous results on the Access Server's ability to evaluate policies in a timely fashion. I do, however, think that adding a capturing feature would lend a powerful and useful capability without significantly degrading performance (then again I could be wrong).

Consider an instance whereby an authenticated user accesses a resource protected by an authorization policy with a URL pattern like the one above. What if there was a authorization rule that caught users that had not updated their profile to accept the latest terms and conditions. The authorization rule would have a action to redirect the user to the new Update Terms and Conditions function, but once they were complete the site would not know what resource to which the user had wanted to go originally. If regex capturing were introduced, however, COREid could capture and store the URL pattern that was matched. This is only part of the solution though; COREid would also need to make the captured pattern available to the authorization rule for use as a parameter in the action. This way the Update Terms and Conditions functionality could be configured to return the user to their originally requested URL.

Comments:
Hi

I have an scenario where I need to protect a pattern /test/app-txt.do, /test/app-txt2.do and so on...
thanks
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?