Be very careful...The injection of the object depends on the scope of
the object being injected. So if you're doing this on a servlet make
sure you annotate the producer with @RequestScoped. Weld will still
build a proxy but this time you will be able to cast the proxy to the
type returned by the producer. So if your producer is:
@Produces
@RequestScoped
public MyCustomPrincipal getCustomPrincipal() { return
howeverYouGetTheCustomPrincipal; }
And your injection point is:
@Inject
Principal principal;
private void someMethod() {
// this cast works because the weld proxy is typed to the return type
of the producer
MyCustomPrincipal mcp = (MyCustomPrincipal) principal;
// you could also inject like this and then you wouldn't have to cast
// @Inject
// MyCustomPrincipal principal;
}
I will ask the weld people if they have any other suggestions.
JJ
On 09/21/2012 10:46 PM, Derek Knapp wrote:
> I have tried casting, and it does not work.
>
> I was able to look up the SessionContext, and call getCallerPrincipal which returned my custom principal.. I will likely wrap this logic, and add a @Produces annotation so I can directly @Inject my custom principal. if anyone has a better way to get my custom principal, please let me know.
>
>
> Derek
>
> On Sep 21, 2012, at 7:20 AM, JJ Snyder<j.j.snyder_at_oracle.com> wrote:
>
>> Derek,
>> Weld, the CDI container, creates a proxy (org.jboss.weld.security.Principal) to the current caller principal (your custom principal). The proxy is always injected so that it can delegate the method calls to the current caller principal. I have not tried it and I doubt it will work but you might be able to cast to your custom type.
>>
>> JJ
>>
>> On 09/21/2012 04:44 AM, Derek Knapp wrote:
>>> Is it possible to @Inject my custom principal in to an ejb?
>>>
>>> It seems that when I inject a principal using,
>>>
>>> @Inject
>>> private Principal principal;
>>>
>>> it returns a org.jboss.weld.security.Principal, which seems to wrap my custom principal (I say this because the toString method uses my custom principal's toString)
>>>
>>> Normally this wouldn't matter, but I actually have some custom data I was hoping to access.
>>>
>>>
>>> Derek
>>>
>>> On Sep 17, 2012, at 11:27 AM, Ron Monzillo<ron.monzillo_at_oracle.com> wrote:
>>>
>>>> On 9/17/12 10:38 AM, Derek Knapp wrote:
>>>>> Is there any way for my custom SAM to use glassfish's build in SSO abilities?
>>>>>
>>>>> If not, anyone have any experience doing SSO across multiple applications with a custom SAM?
>>>> Derek,
>>>>
>>>>
>>>> Yes, by using a proprietary extension to the Servlet Profile of JASPIC, a SAM can tell the Glassfish
>>>> Servlet container to "register" an authentication session.
>>>>
>>>> From validateRequest, and after having used the container callback handler to
>>>> set the caller identity, the SAM would return the following key value pair in the MessageInfo (map)
>>>>
>>>> key = "com.sun.web.RealmAdapter.register"
>>>> value = "true"
>>>>
>>>> Then when the SAM returns to the container, with return value AuthStatus.SUCCESS,
>>>> the container will bind the request to a container authentication session.
>>>>
>>>> Ron