Yeah it is more clear now :)
It seems your proposal is different from Alex. Basically, what I did was based on his initial proposal and considering the following requirements:
* Obtain `Caller` instances even if they are not authenticated. So we just load an account from an repository.
* Obtain credentials from an identity store. Sometimes it may be useful depending on the authentication mechanism being used.
* Group mapping.
* Permission mapping.
I think the size can be explained or even justified based on the different requirements that we are considering in our proposals. Yours is basically providing an authentication method and another to load roles. Where Alex and mine is providing more capabilities. Maybe we should align these requirements first ?
Thanks.
Pedro Igor
----- Original Message -----
From: "arjan tijms" <arjan.tijms_at_gmail.com>
To: jsr375-experts_at_javaee-security-spec.java.net
Cc: "Alex Kosowski" <alex.kosowski_at_oracle.com>
Sent: Monday, June 22, 2015 10:21:52 AM
Subject: [jsr375-experts] Re: Identity Store Proposal 2.0
Hi,
On Mon, Jun 22, 2015 at 2:50 PM, Pedro Igor Silva <psilva_at_redhat.com> wrote:
> Hi Arjan,
> Let's take the SecurityContext discussion aside.
Sure, let's park it for another discussion thread ;)
> From a pure Identity Store API perspective, how my proposal is different than yours ? It is basically encapsulating a repository such as LDAP, database or whatever ...
I think it's basically a matter of size. I'd like to see if we can get
away with the most utterly simply store interface that we can think of
it. Shaving each and every piece of it that's not strictly necessary.
In the repo you linked the IdentityStore interface looks like this:
public interface IdentityStore extends Serializable {
// credential management
Support getCredentialSupport(Class<? extends Credential> credentialType);
<C extends Credential> C getCredential(Caller caller, Class<C>
credentialType);
Credential verifyCredential(Credential credential);
// caller management
Caller getCaller(String callerName);
List<Caller> getCallers(String regEx);
// role management
List<Role> getRoles(String regEx);
// role mapping
List<Role> getRoles(Caller caller);
boolean hasRole(String roleName, Caller caller);
boolean hasRole(String roleName, Group group);
// group management
List<Group> getGroups(Caller principal);
// group mapping
boolean isMember(Caller principal);
// permission mapping
PermissionCollection getPermissions(Caller principal);
}
That's quite a lot of methods IMHO to implement.
The way I see it, there are only 3 pieces of truly essential information:
1. Input: Credential
2. Output: Username and roles
So the most minimal interface around this has some options, but all of
them only focus on just these 3 pieces of information.
In Reza's proposal we had this (I stripped away the implementation and
comments):
@IdentityStore
public class MyIdentityStore {
@OnAuthentication
public Principal getPrincipal(String username, String password) {
}
@OnAuthorization
public String[] getRoles (Principal principal) {
}
}
That's 2 methods.
A 1 method variant on this could be:
@IdentityStore(UsernamePassword.class)
public class MyIdentityStore {
@OnAuthentication
public AuthenticationResult authenticate(Credential credential) {
}
}
Where AuthenticationResult is a holder type for the username, roles
(optional) and maybe an outcome (true/false, or something else).
or based on interfaces:
public class MyIdentityStore implements UsernamePasswordStore {
public AuthenticationResult authenticate(Credential credential) {
}
}
There are a lot of variants that we can think of;
1. A single method (store can be stateless/non-scoped then)
2. Two or three methods (store is then stateful/scoped)
3. Interfaces or annotations
4. General Credential type, interface method per credential type or
annotation per credential type
But the core idea would be that the basic (most minimal) identity
store would only be about {credential -> username/roles}.
Hope this makes is more clear ;)
Kind regards,
Arjan Tijms