Hi,
just wanted to add that I found another solution. The short answer is:
* Add our custom Principal to the principals of the subject inside our
own LoginModule
So, we just don't need any access to the Subject, because the
"getCallerPrincipal" methods always return our own one.
The longer answer is this:
The above "just works" because the implementation of the Subject backs
the Set<Principal> by a LinkedList and therefore preserves insertion
order. Furthermore, the code in
com.sun.enterprise.security.SecurityContext is responsible that this
method works as it just sets the first Principal of the Subject as the
"initiator", which is then used in return for the getCallerPrincipal()
value. And as we added the first one ours is returned here. Works fine,
at least inside an EJB Interceptor (fronted by an OSGi service).
However, a "standard" PrincipalImpl is still added to the subject. So if
we might have to check multiple Principals to e.g. check application
level security we still need access to the subject. But there is another
method of obtaining it which results in the exact same instance as the
proprietary does:
(Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
Well, this works fine currently, but does it still if we turn on the
SecurityManager? We are currently test with it still being disabled.
Cheers,
Kane
On 02/08/2011 03:03 AM, Kumar.Jayanti wrote:
> On 08/02/11 12:31 AM, Marvan Spagnolo wrote:
>> Hello Kumar,
>>
>> thank you for your reply, I was thinking of adding my custom
>> principals along the ones that AppservPasswordLoginModule normally sets.
>>
>> This way I hope not to break the underlying container authorization
>> framework and still make use of it.
>> In my use case I need the custom principals only for doing some more
>> advanced authorization control on top of normal authentication.
>> The checking would be performed in an interceptor around EJB method
>> invocations and inside a few servlets.
>>
>> For doing so I will need to have access to the Subject to retrieve the
>> full list of principals, both from servlets and EJBs.
>> Is this approach feasible ? I'm particularly worried about how to
>> actually access the subject.
>>
>> My first tests with
>>
>> Subject subject = Subject.getSubject(AccessController.getContext());
>>
>> inside the interceptor have returned a null subject.
> GF does not set the Subject in AccessControlContext for performance
> reasons.
> You can use :
> com.sun.enterprise.security.SecurityContext.getCurrent().getSubject().
>
> But then: it is not a public API intended for end-users.
>
> regards,
> kumar
>
>
>>
>> Cheers,
>>
>> Reza Marvan Spagnolo
>>
>>
>> On Mon, Feb 7, 2011 at 12:18 PM, Kumar.Jayanti
>> <Vbkumar.Jayanti_at_sun.com <mailto:Vbkumar.Jayanti_at_sun.com>> wrote:
>>
>> On 07/02/11 4:41 PM, Kumar.Jayanti wrote:
>>
>> On 07/02/11 4:35 PM, Marvan Spagnolo wrote:
>>
>> Hi all,
>>
>> in the company I work for we've a project where we setup
>> Glassfish with a custom realm and a custom login module.
>> So far, we have more or less followed what is highlighted
>> in the "Oracle Glassfish Server 3.0.1 Application
>> Development Guide"
>> in the section "Realm Configuration", thus we've
>> overridden the authenticate() method while extending
>> AppservPasswordLoginModule
>> (and provided also our custom realm).
>>
>> What I would like to do now is to provide a custom class
>> implementing Principal and setting in the subject those
>> custom principals upon
>> successful authentication.
>>
>> I've read in the guide mentioned above that I should never
>> override the commit method, yet it seems the only possible
>> way to insert
>> custom principals in the subject, especially when I then
>> read in the javadoc of the public method
>> AppservPasswordLoginModule#getSubject() the following:
>>
>> [...]
>> A custom login module could overwrite commit() method, and
>> call getSubject()
>> to get subject being authenticated inside its commit().
>> Custom principal then can be added to subject.
>> [...]
>>
>> So the code seems to be negating what the guide says, I am
>> inclined to follow what is suggested in the code, but what
>> do you people think ?
>> What is the best practice for setting custom principals in
>> a custom realm scenario ?
>>
>> You could do that. But be aware that the Custom Principal will
>> not be used by the container Authorization framework. Is that
>> fine for your usecase ?.
>>
>> We had a planned item SEC-011 that we did not address in V3.1. It
>> will be a candidate for V3.2.
>>
>> http://wikis.sun.com/display/GlassFish/3.1NewSecurityFeatures
>>
>> regards,
>> kumar
>>
>>
>> Thanks in advance,
>>
>> Reza Marvan Spagnolo
>>
>>
>>
>>
>