Returns the primary principal used application-wide to uniquely identify the owning account/Subject. <p/> The value is usually always a uniquely identifying attribute specific to the data source that retrieved the account data. Some examples: <ul> <li>a {@link java.util.UUID UUID}</li> <li>a {@code long} value such as a surrogate primary key in a relational database</li> <li>an LDAP UUID or static DN</li> <li>a string username unique across all user accounts</li> </ul> <h3>Multi-Realm Applications</h3> In a single-{@code Realm} application, typically there is only ever one unique principal to retain and that is the value returned from this method. However, in a multi-{@code Realm} application, where the {@code PrincipalCollection} might retain principals across more than one realm, the value returned from this method should be the single principal that uniquely identifies the subject for the entire application. <p/> That value is of course application specific, but most applications will typically choose one of the primary principals from one of the {@code Realm}s. <p/> Shiro's default implementations of this interface make this assumption by usually simply returning {@link #iterator()}.{@link java.util.Iterator#next() next()}, which just returns the first returned principal obtained from the first consulted/configured {@code Realm} during the authentication attempt. This means in a multi-{@code Realm} application, {@code Realm} configuration order matters if you want to retain this default heuristic. <p/> If this heuristic is not sufficient, most Shiro end-users will need to implement a custom {@link hunt.shiro.authc.pam.AuthenticationStrategy}. An {@code AuthenticationStrategy} has exact control over the {@link PrincipalCollection} returned at the end of an authentication attempt via the <code>AuthenticationStrategy#{@link hunt.shiro.authc.pam.AuthenticationStrategy#afterAllAttempts(hunt.shiro.authc.AuthenticationToken, hunt.shiro.authc.AuthenticationInfo) afterAllAttempts}</code> implementation.
Returns a single Subject's principals retrieved from all configured Realms as a List, or an empty List if there are not any principals. <p/> Note that this will return an empty List if the 'owning' subject has not yet logged in.
Returns a single Subject's principals retrieved from all configured Realms as a Set, or an empty Set if there are not any principals. <p/> Note that this will return an empty Set if the 'owning' subject has not yet logged in.
Returns a single Subject's principals retrieved from the specified Realm <em>only</em> as a Collection, or an empty Collection if there are not any principals from that realm. <p/> Note that this will return an empty Collection if the 'owning' subject has not yet logged in.
Returns the realm names that this collection has principals for.
Returns {@code true} if this collection is empty, {@code false} otherwise.
EXPERIMENTAL - DO NOT USE YET <p/> A {@code PrincipalMap} is map of all of a subject's principals - its identifying attributes like username, userId, etc. <p/> The {@link Map} methods allow you to interact with a unified representation of all of the Subject's principals, even if they came from different realms. You can think of the {@code Map} methods as the general purpose API for a Subject's principals. That is, you can access a principal generally: <pre> Object principal = subject.getPrincipals().get(principalName); </pre> For example, to get the Subject's username (if the username principal indeed exists and was populated by a Realm), you can do the following: <pre> string username = (string)subject.getPrincipals().get("username"); </pre> <h3>Multi-Realm Environments</h3> If your application uses multiple realms, the {@code Map} methods reflect the the aggregate principals from <em>all</em> realms that authenticated the owning {@code Subject}. <p/> But in these multi-realm environments, it is often convenient or necessary to acquire only the principals contributed by a specific realm (often in a realm implementation itself). This {@code PrincipalMap} interface satisfies those needs by providing additional realm-specific accessor/mutator methods.
@author Les Hazlewood