>--Original Message Text---
>From: Keith L. Musser
>Date: Thu, 23 Nov 2000 10:19:04 -0500
>
>Oleg
>
>I looked into this a little more this morning. I would not suggest committing that
>"work around", as I don't >think it really
properly solves the problem.
>
>Here's what I'm thinking. I think the following should be handled in the
>SecurityInterceptor, in the sequence >specified for each
invoke and invokeHome call:
>
>(1) authenticate caller principal, as set by client
>(2) realm mapping - run as what principal
>(3) checking permissions - for the mapped principal
>(4) associate the mapped principal / credential with thread
>(5) invoke next level interceptor
>(6) associate original client principal / credential with thread
The purpose of realm mapping is not to change the identity of who is running the
code. It is to map from the security domain nomenclature used by the bean
developer onto the deployment environment security domain. Step 3 above,
uses the roles as described application deployment descriptor for permission
checks because that is how the method permission were defined. The identity of
the one running the code should not be set to a mapped role as the mapped role
can have no meaning in the deployment security domain and there can be other
permission checks that are described with respect to the authenticated principal.
One example of such a check is using a JAAS Subject based policy to describe
permissions that cannot be described using the role based security model.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
