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)
>
True, so if the caller of the identity store wants to have either a full
Principal or a String, then just the Principal satisfies both cases.
On the other hand, if the caller can accept both, then it basically always
has to use the Principal form since it doesn't know which form the identity
store prefers. Now this isn't necessarily bad, just something to take into
account.
A small extra thing to take into account is that GlassFish has a bug with
handling Principals. The effect is that request.getUserPrincipal() always
returns a GlassFish Principal wrapper, which has the correct value for
getName() but not the correct type itself. Payara already fixed this bug.
See
https://java.net/jira/browse/GLASSFISH-16587 and
https://github.com/payara/Payara/issues/290
> It also allows you to create a Principal for those cases where we use
> external authentication (OAuth2/OpenID/SAML/...) since a Principal is used
> a lot nowadays. (with a proper identityStore which adds for instance the
> groups/roles to the mix for those authentication protocols which don't
> supply this information)
>
This identity store variant for OAuth2/etc purposes is what my friend Jan
used for his "SocialServerAuthModule" here:
https://github.com/omnifaces/omnisecurity-socialauth/blob/develop/src/main/java/org/omnifaces/security/socialauth/jaspic/authmodules/SocialServerAuthModule.java#L258
It's another thing we may have to look at. Is it just a matter of "special
credentials" (here it's {socialAuthManager, profile}), or is a bit more
needed?
Kind regards,
Arjan Tijms
>
>
> Although I'm not a fan of returning 'authorisation' info (like groups and
> roles) in the method where we do 'authentication'. Could be a separate
> method but I realise that it is a common practice today (to return both)
>
> For me, not everything needs to be an interface. Implementations can
> always extend the class and add their additional methods.
>
> Question:
> There are 3 annotations defined for concrete implementations of the
> IdentityStore. How is a custom definition found by the system?
> Should we consider also CDI beans which implement the IdentityStore
> interface?
>
> Hope to see other people their comments or approval to your nice proposal.
>
> regards
> Rudy
>
>
>
>
>
>
>
> On 29 December 2015 at 16:47, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
>> Hi,
>>
>> I think we're quite close to a final proposal for the identity store
>> interface. The latest proposal is really quite workable. See
>> https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/authentication/identity-store/identity-store-readonly-simplified
>>
>>
>> There are however a few things that I think could still be improved.
>>
>> Currently not all types are fully interface based. E.g.
>> CredentialValidationResult is now a class and not an interface. For a spec
>> with a clear API/implementation split I think CredentialValidationResult
>> could better be an interface, with the implementation being provided by the
>> RI.
>>
>> See
>> https://github.com/javaee-security-spec/javaee-security-proposals/blob/master/authentication/identity-store/identity-store-readonly-simplified/src/main/java/javax/security/identitystore/CredentialValidationResult.java
>>
>> Another thing is that there's no support for a custom Principal now. This
>> again concerns CredentialValidationResult, which now only contains a
>> "String getCallerName()".
>>
>> What we could do is add a "Principal getCallerPrincipal()" method, OR an
>> "Optional<Principal> getCallerPrincipal()" method.
>>
>> Semantics would be that if Principal is not-null/present then the custom
>> principal is to be used, otherwise the getCallerName() has to be used.
>>
>> Alternatively, we only define a getPrincipal() method. This could even
>> possibly return a subtype of java.security.Principal,
>> say javax.security.CallerPrincipal (an interface too). Default identity
>> stores would then return a direct implementation of
>> javax.security.CallerPrincipal, where custom identity stores can return a
>> more elaborate implementation with fields that only the application knows
>> about.
>>
>> Thoughts?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>