Tuesday, June 26, 2012
Liferay Portal: Authorization (Part Two)
Previously, I blogged on ways Liferay Portal could improve its approach to authentication. Today, I am focused on authorization and entitlements...
The model for how Liferay handles authorization and entitlements is rock solid. It can not only handle defining both coarse and fine-grained entitlements within its own but can also be easily externalized to third party products such as Axiomatics, Securent and others that leverage the XACML standards. This is easily accomplished by implementing the Liferay PermissionsChecker interface and registering it with Liferay.
Still there are a few gaps that it doesn't quite account for. Below are a few scenarios that come to mind.
Availability
When developing portal-based applications, especially those that invoke downstream services, one cannot always count on a resource being available especially in an enterprise setting. Many systems have scheduled outages whereby it makes zero sense to even present an option to the user to invoke them. The ideal scenario would be to have the ability to define a calendar object where an administrator could attach the availability to a given portal resource.
The calendar could either enumerate times of availability or inavailability depending upon culture. Equally there are times where you may not want users to access the portal in its entirety and this could equally be accomplished by first making the Login portlet unavailable. In addition to needing some way to express a calendar, Liferay would also need a way to propagate available/unavailable messages to portlets.
Credential strength
When Liferay is used in higher profile applications, it becomes vital to understand what exact credential was used at authentication time. Surely, we understand that authenticating via username/password would be less secure than authenticating via digital certificates.Taking this one step further, you may sometimes need to restrict access to a resource if they used a lower strength credential to authenticate.
Location
Imagine standing up a banking application using Liferay portal. Would it ever make sense to allow an administrator to perform administrative activities when his/her IP address indicates they are currently in Iran? The ability to restrict highly privileged accounts is a given. It is sometimes important to also restrict regular users from accessing certain resources as well. For example, what if you wanted to have a policy that allows a person to view their paystubs via a portlet but only from a work location? One could always embed these types of checks within the portlet itself, but doesn't it make sense to not couple a security concern with business functionality.
Secure Channel
For applications that handle sensitive information, whether credit cards, health information, etc, an administrator should be able to define certain resources as being accessible only via a secure channel.
| | View blog reactionsThe model for how Liferay handles authorization and entitlements is rock solid. It can not only handle defining both coarse and fine-grained entitlements within its own but can also be easily externalized to third party products such as Axiomatics, Securent and others that leverage the XACML standards. This is easily accomplished by implementing the Liferay PermissionsChecker interface and registering it with Liferay.
Still there are a few gaps that it doesn't quite account for. Below are a few scenarios that come to mind.
Availability
When developing portal-based applications, especially those that invoke downstream services, one cannot always count on a resource being available especially in an enterprise setting. Many systems have scheduled outages whereby it makes zero sense to even present an option to the user to invoke them. The ideal scenario would be to have the ability to define a calendar object where an administrator could attach the availability to a given portal resource.
The calendar could either enumerate times of availability or inavailability depending upon culture. Equally there are times where you may not want users to access the portal in its entirety and this could equally be accomplished by first making the Login portlet unavailable. In addition to needing some way to express a calendar, Liferay would also need a way to propagate available/unavailable messages to portlets.
Credential strength
When Liferay is used in higher profile applications, it becomes vital to understand what exact credential was used at authentication time. Surely, we understand that authenticating via username/password would be less secure than authenticating via digital certificates.Taking this one step further, you may sometimes need to restrict access to a resource if they used a lower strength credential to authenticate.
Location
Imagine standing up a banking application using Liferay portal. Would it ever make sense to allow an administrator to perform administrative activities when his/her IP address indicates they are currently in Iran? The ability to restrict highly privileged accounts is a given. It is sometimes important to also restrict regular users from accessing certain resources as well. For example, what if you wanted to have a policy that allows a person to view their paystubs via a portlet but only from a work location? One could always embed these types of checks within the portlet itself, but doesn't it make sense to not couple a security concern with business functionality.
Secure Channel
For applications that handle sensitive information, whether credit cards, health information, etc, an administrator should be able to define certain resources as being accessible only via a secure channel.
