Hi,
On Wed, Apr 15, 2015 at 9:45 AM, Adam Bien <abien_at_adam-bien.com> wrote:
> But if the extensibility is requested a lot, why not just add a method Map<String,Object> getContext() (and setter) to the Principal?
Well, maybe because it would reinforce the idea that a Principal IS
the user, while with the current definition in place a Principal is
more akin to an attribute that belongs to an authenticated identity
(which is represented by the Subject).
From the Javadoc of Subject
(
https://docs.oracle.com/javase/8/docs/api/javax/security/auth/Subject.html)
" Principals simply bind names to a Subject. For example, a Subject
that happens to be a person, Alice, might have two Principals: one
which binds "Alice Bar", the name on her driver license, to the
Subject, and another which binds, "999-99-9999", the number on her
student identification card, to the Subject. Both Principals refer to
the same Subject even though each has a different name."
It's understandable people want to think the Principal is the user,
since it's the only thing that Servlet, JAX-RS, CDI and EJB directly
exposes.
The question is whether extra information (I assume things like
"address" and "age", etc?) are best represented by extra Principals.
If so, do we want to standardize a few of these, like
AddressPrincipal, AgePrincipal, etc?
Btw, another issue here is that Principal is a Java SE interface
(
https://docs.oracle.com/javase/8/docs/api/java/security/Principal.html)
We can't just add a method to it.
> or expose the public part of the Subject?
> We could also make the Subject injectable with @Inject (built-in CDI bean)
In Java EE you should already be able to obtain the Subject programmatically:
Subject subject = (Subject)
PolicyContext.getContext("javax.security.auth.Subject.container");
Would be trivial to define a CDI producer for this.
But there are two problems with this:
* It's only specified to be available this way in Java EE full profile
implementations
* A large amount of full profile implementations have misinterpreted
the spec and don't actually support this or only support it after
making vendor specific configuration changes to the product.
> In JAX-RS we can just reference the HttpServletRequest, with @Context but it is ugly. I think there is room for simplification.
I hear you. This is where the global CDI injectable security context comes in ;)
See
https://java.net/jira/browse/JAVAEE_SECURITY_SPEC-12
Kind regards,
Arjan Tijms
>
>>
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>> 6. user management
>>>
>>> I would like to create a simplistic Java EE application(s) (max 5 classes) and try to implement the use cases above with minimal required code.
>>> If necessary with proprietary APIs, which hopefully are going to be replaced by standard spec as we progress.
>>> We could use this application for further discussion and further simplification and usability enhancement,
>>>
>>> what do you think?
>>>
>>> cheers,
>>>
>>> adam
>>>
>>>
>>>
>