[jboss-jira] [JBoss JIRA] (ELY-366) Clarify realm read/update semantics

[David Lloyd (JIRA)]

    [ https://issues.jboss.org/browse/ELY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13127910#comment-13127910 ] 

David Lloyd commented on ELY-366:
---------------------------------

This also has impact related to the Brno discussion around OTP and ensuring only one simultaneous authentication at a time.  I think that this should be credential-oriented though, and separate.  I imagine a semantic write lock would be acquired on *just* the credential in question as soon as it is acquired (or possibly, as soon as it is verified, which would minimize the window), and released at {{destroy()}} time.  This is in addition to (and after) the identity-wide read lock.

Note that this credential-scoped OTP write lock cannot be acquired any later than the first point at which the credential is used for verification.

> Clarify realm read/update semantics
> -----------------------------------
>
>                 Key: ELY-366
>                 URL: https://issues.jboss.org/browse/ELY-366
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Realms
>            Reporter: David Lloyd
>
> The following points are currently true:
> * Identities are "created" via {{SecurityRealm.createRealmIdentity(name)}}
> * These identities are not really *created* at this time; this just creates a handle by which the identity can be queried
> * Identity access has a bound lifecycle
> * Identity access is not atomic - an identity can be updated as it is accessed
> * Modifiable realm identities use the same "create" mechanism but with an extra method to actually realize them within the realm
> I propose the following changes:
> * {{createRealmIdentity}} should be changed to {{getRealmIdentity}}
> * {{ModifiableSecurityRealm}} should no longer override this method, instead introducing a new method {{getRealmIdentityForUpdate}} which returns a {{ModifiableRealmIdentity}}
> * Semantically, a read lock (or equivalent) is held during the lifecycle of {{RealmIdentity}} and a write lock (or equivalent) is held during the lifecycle of {{ModifiableRealmIdentity}}
> * Locks are released when the identity is destroyed
> * AuthorizationIdentity generally should be an immutable snapshot
> This will ensure the atomicity of all authentication and authorization operations.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)