> On 15.04.2015, at 11:51, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> 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?
In the past we “subclassed” Principal and stored a bunch of different things inside. I’m not sure about the standardized abstractions.
>
> 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.
A built-in bean is effectively a standardized CDI producer.
>
> 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.
This could be fixed in Java EE 8
>
>
>> 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
Voted and commented. We could implement a fake SecurityContext and use it for demo purposes.
cheers,
adam
>
> 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
>>>>
>>>>
>>>>
>>