Hi,
On Sun, Jan 3, 2016 at 5:00 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> Not entirely sure, if we should add classes directly into the alread
> crowded "javax.security" root package (see
> https://docs.oracle.com/javase/8/docs/api/java/security/package-summary.html
> for Java SE 8 which we'll build upon in EE 8) but the idea feels good..
>
Still not entirely sure either. Do note the package you refer to is
"java.security", this is intended for "javax.security". If I'm not
mistaken there are no types yet in that package, only the two sub-packages
jacc and auth.message.
> Hope some of those proposals could be gathered in the "Security Proposals"
> sandbox repo or better an EDR version of the actual API;-)
>
I copied the most important proposals to the sandbox repo already. This
latest change is a (small) variation on
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/authentication/identity-store/identity-store-readonly-simplified
I'll ponder over the pre-proposal a little and copy it to the
javaee-security-proposals later then.
Some questions still:
* Should API be fully interfaces based? (Rudy thinks not, any other
opinions?)
* Specifically, should javax.security.CallerPrincipal be an interface?
* Should all JSR 375 methods that deal with a caller Principal actually be
of type CallerPrincipal or the more general Principal? (I'm leaning towards
CallerPrincipal, but would like to hear other opinions)
Kind regards,
Arjan Tijms
>
> Cheers,
> Werner
>
> On Sat, Jan 2, 2016 at 11:25 PM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> On Wed, Dec 30, 2015 at 12:08 PM, Rudy De Busscher <rdebusscher_at_gmail.com
>> > wrote:
>>
>>> I would use a Principal instead of the "String getCallerName()". It
>>> also has the getName() method and has the benefit that an implementation
>>> can return a subtype of java.security.Principal. (as you mention)
>>>
>>
>> I did a quick implementation of this here:
>> https://github.com/arjantijms/mechanism-to-store-x/commit/b8522ee7c60de2ad2b11e00dddcd8e1a45b3e4d0
>>
>> For this I introduced a new type, javax.security.CallerPrincipal. It's a
>> class for now, but maybe this one can better be an interface (not sure
>> yet). Another thing it was contemplating is adding a wrapper type,
>> e.g. javax.security.CallerPrincipalWrapper, for when an existing Principal
>> needs to be used that can not be made to extend or
>> implement javax.security.CallerPrincipal.
>>
>> I'm not 100% sure if we can add types to javax.security directly, but
>> since the JSR proposed "javax.security" I guess we can.
>>
>> The nice thing of consistently using CallerPrincipal is also that it sort
>> of standardises the Principal type used for the caller principal (something
>> Java EE failed to do before). Of course to really standardise it some more
>> work is needed (alignment with JASPIC, JACC, Servlet, etc).
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>
>