Alan,
OK thanks that clarifies it. I thought you meant that the user's roles were determined and locked down at deployment time, but you meant that the roles defined in the deployment descriptor are converted to permissions and locked down.
cheers, Jan
-----Original Message----- From: Jan Bartel [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 4:22 PM To: [EMAIL PROTECTED] Subject: Re: Jetty and JACC
Alan,
The mapping of Permissions to principals using roles occurs at configuration time. Look at PolicyConfiguration.commit(), this is
where
the mapping takes place and allows for a simple permission check w/
a
principal instead of mapping roles on the fly. This is an important difference, once commit is called, roles are no longer used since
all
permissions have been directly mapped to principals.
I'm still missing a piece of the puzzle (musn't have had enough coffee this morning). I understand that at deploy time for a webapp, the web.xml is parsed and a bunch of policy statements are created and loaded into the Policy provider. These policy statements are then evaluated at runtime by the Policy at the instigation of the
container.
Some checks involve the identity of the user executing the code and
the
roles that the user has been granted. Usually, the roles for a user
are
discovered and cached when the user authenticates . Are you saying
that
this dynamic behaviour is no longer possible and that the container
must
load all users and their roles once-only at deploy time instead so
that
they can be mapped to Permissions? If so, then I have two concerns: 1) scalability 2) manageability.
I'm probably over explaining everything. I think that we're saying the same thing. I just want to stress that after deployment, roles are no longer directly used. A user's principals are obtained at login, this is virtually the same as saying the "roles for a user are discovered and cached when the user authenticates".
Thanks for the JettyWebApplicationContext stuff, have you committed
it?
cheers Jan
