Community
Participate
Working Groups
Using the subject as a mechanism for running code under an identity is one of the promising uses for JAAS. One of the advantages is that permissions can then be scoped on a user-identity basis as well as codesource and signer. There are a couple issues that need resolving if we want to consider this usage. 1. We need a model for when and how Subject.doAs should be done in code (e.g.: whose responsibility it is to invoke: platform or application? does it integrate nicely with the Jobs framework? the RCP application lifecycle?) 2. The subject is not always available in a context - in particular within a doPrivileged block. This limits the usefulness of the subject as a default container for identity and credentials. See: http://www.skywayradio.com/tech/WAS51/JAAS_authorization.php for more information. The concept of code execution identity and its scope might be a good discussion for OSGi proper. Thoughts?
(In reply to comment #0) > 1. We need a model for when and how Subject.doAs should be done in code (e.g.: > whose responsibility it is to invoke: platform or application? does it > integrate nicely with the Jobs framework? the RCP application lifecycle?) It is up to what ever entity is aware of the concept of a user. For app servers, a servlet may require the user to authenticate and can then used the user as a subject. If the platform requires the user to authenticate when starting the platform, then the platform has a subject to use. So I don't think there is a good rule to define here. It depends upon how users are identified and whether the user has associated permissions. > 2. The subject is not always available in a context - in particular within a > doPrivileged block. This limits the usefulness of the subject as a default > container for identity and credentials. See: > > http://www.skywayradio.com/tech/WAS51/JAAS_authorization.php > That paper only seems to reference a bug in some 1.3 java from IBM. I did not get the sense from that article that doAs gets lost by doPriv except for that bug. > The concept of code execution identity and its scope might be a good discussion > for OSGi proper. The OSGi permission model (ConditionalPermissionAdmin and/or PermissionAdmin) only supports the concept of code based permissions. Work is needed to understand how to support user based permissions.
Moving to security component.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
