Hi Damon,
All very interesting. Our App is currently all PHP so knows nothing of
"Roles" as such. We use internal roles, i.e.:
1. user
2. team leader
4. auditor
8. admin
And bit shift them to see if a given user can access that page (in php: if
(!role & page_protect) { //kick them out }}
Now, not knowing a hell of a lot about Java, should my application actually
use low level Java roles? Or should I just be happy for my role based auth
to happen at the app level?
Cheers,
Matt
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Damon Rand
Sent: Thursday, November 27, 2003 12:33 PM
To: OXF Users
Subject: Re: Once a user is logged in ...
> Hey All;
Hi Matt,
> Our App is only accessible once a user logs in. The login.xpl
> confirms their identity and loads their info into the session.
>
> For all the pages that required a user to be logged in, I obviously
> need
to
> check that they are logged in and their role allows them to get to
> that appropriate page. The are logged in via a web form rather than a
> HTTP
creds
> box.
This is pretty much what I am working on at the moment too. Here are some
comments.
Container level:
==========
- I have got a JNDIRealm in the tomcat context.xml that authenticates the
users from LDAP using credentials from the form based logins.
- I am using the 'userRoleName' in the jndirealm to map an orgunit
attribute to a Tomcat role. This gives me one set of roles.
- Allow all named roles access into the root.
<url-pattern>/</url-pattern>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
- I am planning an additional set of application specific groups
'Myapp.Administrators' in the LDAP directory. These groups will be used to
provision the administrator role using the rolebase and rolesearch in
JNDIRealm.
- Optionally restrict url access based on the user being in the right
orgunit OR having administrator rights.
<url-pattern>/orgunit1/*</url-pattern>
<auth-constraint>
<role-name>administrator</role-name>
<role-name>orgunit1</role-name>
</auth-constraint>
Application level:
============
If necessary do more fine-grained security in the application.
- In OXF you can use the request-security generator to get at the container
roles.
- Use the ldap processor to add extra roles that couldn't be done at
container level to the users sessions.
- Within all model.xpl and action.xpl files redirect users manually to the
login page if they are not in the right role.
- Within views you can use <xsl:if test="{role select}"/> in the view to
show/hide/grey-out action links.
> My question is this, what is the most graceful way to check that they
> are logged in and have the correct permissions to be there on each
> page that required it?
Perhaps the web application controller could have some simple role-based
security added to it.. Something allow the lines of..
<page id="myid" path-info="/photo.html" model="oxf:/photo.xpl"
view="oxf:/photo.xhtml" deny="guest">
<action when="/form/action = 'delete'" action="oxf:/action.xpl"
grant="administrator"/>
</page>
This way we don't need code in the model.xpl or action to check the users
permissions.
Addendum:
========
Going quite a lot further down the application level security track gets you
too the idea of OXF xacl extensions to some of the main processors.
http://www.trl.ibm.com/projects/xml/xss4j/docs/xacl-readme.html
<policy>
<xacl>
<object href="/"/>
<rule>
<acl>
<subject>
<group>my group</group>
</subject>
<action name="read" permission="grant"/>
</acl>
</rule>
</xacl>
</policy>
The processor extensions could be:
- input -> Policy xml containing xacl elements.
- input -> Security principal/info (username + list of groups the user
belongs to)
- input -> A piece of xml that the xacl references (probably by id rather
than href?).
- output -> The original piece of xml marked up with grant/deny attributes.
Here is an interesting use case for these processor extensions:
- A controller.xml file contains a list of all the pages in an application
and the actions associated with each page.
- An ldap user object contains a list of all groups a user belongs too.
- A policy document contains acls for each page and action, etc.
<p:processor uri="oxf/processor/identity">
<p:input name="data">
<controller>
<page id="1">
<action id="a1.1" />
</page>
<page id="2"/>
</controller>
</p:input>
<p:input name="associated-policy" href="" />
<p:input name="associated-status" href="" />
<p:input name="associated-context" href="" />
<p:output name="data" id="output"/>
</p:processor>
- Output should contain a sitemap document that only contains pages/actions
the user has access too.
- Use the output and an xslt to generate the application menu and action
list..
Regards,
Damon.
_______________________________________________
oxf-users mailing list
[EMAIL PROTECTED]
http://mail.orbeon.com/mailman/listinfo/oxf-users
_______________________________________________
oxf-users mailing list
[EMAIL PROTECTED]
http://mail.orbeon.com/mailman/listinfo/oxf-users
