[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=13127911#comment-13127911 ] 

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

A sufficiently clever realm implementation could even release the credential write lock as soon as the auth complete realm event is delivered and acted upon.

> 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)