1. Cryptography
1.1. Easy of Use
1.2. Best practices backed into it
1.3. Uses underline providers can work with any JCA provider
1.4. Type of Cypher
1.5. Example
1.5.1. AES Encryption with IV
1.5.2. SHA256 Hash
1.6. Message Digest
2. Session Management
2.1. Faetures
2.1.1. POJO/J2SE based
2.1.2. Easy Custom Session Storage
2.1.3. Not dependent on Web
2.1.4. For web container uses underline HTTP Session
2.1.5. Same session can be accessed from many clients
2.1.6. Container-Independent Clustering
2.1.7. Session Event listener
2.1.8. Host Address Retention
2.1.9. Inactivity/Expiration Support
2.1.10. Can be used for SSO
2.2. API
2.2.1. SecurityUtils.getSubject().getSession()
2.2.2. sessionManager.globalSessionTimeout
2.2.3. SessionManager
2.2.3.1. DefaultSessionManager
2.2.4. SessionDAO
2.2.4.1. Only used for native Shiro sessions not for web sessions
2.2.4.2. EHCache SessionDAO
2.2.4.2.1. Support Container Independent Session Clustering
2.2.4.2.2. EnterpriseCacheSessionDAO
2.2.5. Session Listener
2.2.5.1. SessionValidationScheduler
2.2.5.2. Must implement SessionListener interface or extend SessionListenerAdapter
2.2.6. Session Clustering
2.2.6.1. Notified when an event occurs for any session
2.2.6.1.1. Ehcache+TerraCotta
2.2.6.2. Only supported with native sessions
2.2.6.3. cluster-capable SessionDAO
2.2.6.3.1. GigaSpaces
2.2.6.3.2. Oracle Coherence
2.2.6.3.3. Memcached
3. Authorization
3.1. Simplified API
3.2. sessionManager.sessionListeners = $aSessionListener, $anotherSessionListener, etc.
3.3. Programmatic, taglib, JSF support
3.4. Example
3.4.1. Show Play button to user with Permission
3.4.2. Only user with Member.Premium.PlayAll permission to play all songs
3.5. Permission
3.6. Roles
3.6.1. Explicit (Preferred)
3.6.1.1. Mapped to set of Permission
3.6.2. Implicit
3.6.2.1. Implies certain behaviors that is hard-coded in source code
3.7. Implementation
3.7.1. hasRole*/checkRole*/isPermitted* /chckPermission* called on Subject (DelegatingSubject)
3.7.1.1. SecurityManger identical method called
3.7.1.1.1. Authorizer(ModularRealmAuthorizer) respective method called
4. Authentication
4.1. Features
4.1.1. Simple API
4.1.2. Pluggable DAO (Realm)
4.1.2.1. Easy to integrate RDBMS/OAUTH/OpenId Connect/LDAP/Sammy
4.1.2.2. Support multiple Realm / Identity Store
4.1.3. Support Multiple Realm
4.1.4. Granular exception handling on login failure
4.1.5. RememberMe
4.2. Terms
4.2.1. Subject (User)
4.2.2. Realm(DAO/Identity Store)
4.2.2.1. Implicit Ordering( Not Preferred)
4.2.2.1.1. Same order as they are declared in shiro.ini file
4.2.2.2. Explicit Ordering
4.2.2.2.1. Explicitly defining order in securityManager.realms property value
4.2.2.2.2. Only relms defined explicitly will be used.
4.2.2.3. Implementation
4.2.2.3.1. AuthorizingRealm
4.2.2.3.2. Credentials Matching
4.2.3. Principals - Subjects identifying attributes (username)
4.2.4. Credentials
4.2.5. Authenticator
4.2.5.1. ModularRealmAuthenticator
4.2.6. AuthenticationStrategy
4.2.6.1. AbstractAuthenticationStrategy is the base class for all Strategy types
4.2.6.1.1. AllSuccessfulStrategy(Dafault)
4.2.6.1.2. FirstSuccessfulStrategy
4.2.6.1.3. AtLeastOneSuccessfulStrategy
4.3. Example
4.3.1. Login using Email
4.3.2. Login using Facebook