Setting Authorization Roles

[neilac333]

I was reading the security documentation for Seam--in particular the simplified mode of authentiction. Everything was pretty straightforward except one thing. I can see how the AuthorizationException gets handled, but how does it get thrown?

Put another way, how do I specify in simplified mode that a page is visible only to certain roles? Is this an attribute in pages.xml?

Thanks.

[shane.bryzak]

You can place a element within a element inside pages.xml, like this:

<page view-id="/orderDetail.xhtml">
 <restrict>#{s:hasRole('admin')}</restrict>
 </page>

[neilac333]

Thanks so much for the prompt response.

[asookazian]

You can place a <restrict> element within a <page> element inside pages.xml, like this:

<page view-id="/orderDetail.xhtml">
 <restrict>#{s:hasRole('admin')}</restrict>
 </page>

What is the recommended alternative implementation strategy to hard-coding the role(s) like above in pages.xml? for example, storing the role information in a RDBMS table so that we can update role data real-time and users are granted roles when they begin a new session.

Is it even necessary to do this? the argument bein that roles for page level access do not change frequently enough to need real-time updates?

Also, is it sufficient in most cases to use s:hasRole for component level restriction on JSF's instead of using s:hasPermission?

[shane.bryzak]

"asookazian" wrote:
What is the recommended alternative implementation strategy to hard-coding the role(s) like above in pages.xml? for example, storing the role information in a RDBMS table so that we can update role data real-time and users are granted roles when they begin a new session.

Is it even necessary to do this? the argument bein that roles for page level access do not change frequently enough to need real-time updates?

I don't quite understand what you're asking here. Storing the user's roles in a database table is a recommended strategy.

"asookazian" wrote:
Also, is it sufficient in most cases to use s:hasRole for component level restriction on JSF's instead of using s:hasPermission?

That totally depends on your own requirements. You can use either, or mix and match as you wish. It all depends on what kind of security model you want and how fine-grained it should be.