Skip to main content

Home/ SoftwareEngineering/ Group items tagged ApacheShiro

Rss Feed Group items tagged

kuni katsuya

AllPermission (Apache Shiro 1.2.1 API) - 0 views

  • AllPermission
  • always implies any other permission
    • kuni katsuya
       
      equivalent to *:*, ie. all actions on all resource types
  • implies method
  • ...2 more annotations...
  • always returns true
  • have the ability to do anything
kuni katsuya

Subject | Apache Shiro - 0 views

  • Understanding Subjects in Apache Shiro
  • 'Subject'
  • is just a security term that means a
  • ...8 more annotations...
  • security-specific 'view'
  • of an application user
  • Subject instance represents both security state and operations for
  • a single application user
  • in the security world, the term 'Subject' is actually the recognized nomenclature
  • Subject currentUser = SecurityUtils.getSubject();
  • obtain the currently executing Subject by using org.apache.shiro.SecurityUtils:
  • Subject based on user data associated with current thread or incoming request.
kuni katsuya

RolePermissionResolver (Apache Shiro 1.2.1 API) - 0 views

  • RolePermissionResolver
  • resolves a String value and converts it into a Collection of Permission instances
  •  Collection<Permission> resolvePermissionsInRole(String roleString)
  • ...2 more annotations...
  • role name to resolve
  • Collection of Permissions
kuni katsuya

Apache Camel: Shiro Security - 0 views

  • Shiro Security Component
  • Available as of Camel 2.5
kuni katsuya

Session Management | Apache Shiro - 1 views

  • Session Clustering
  • can cluster Subject sessions natively and never need to worry again about how to cluster sessions based on your container environment
  • if you configure a cluster-capable SessionDAO, the DAO can interact with a clustering mechanism and Shiro's SessionManager never needs to know about clustering concerns
  • ...8 more annotations...
  • Therefore enabling Session clustering in Shiro is
  • as simple as configuring Shiro to use a distributed cache
  • Ehcache+TerraCotta
  • When Shiro initializes the
  • SessionDAO implements the CacheManagerAware interface
  • call the
  • setCacheManager
  • Ehcache + Terracotta
kuni katsuya

Session Management | Apache Shiro - 0 views

  • available in any application,
  • regardless of container.
  • even if you deploy your application in a Servlet or EJB container, there are still compelling reasons to use Shiro's Session support instead of the container's
  • ...40 more annotations...
  • Easy Custom Session Storage
  • POJO/J2SE based (IoC friendly)
  • Container-Independent Clustering!
  • Heterogeneous Client Access
  • Event Listeners
  • listen to lifecycle events during a session's lifetime
  • Host Address Retention
  • retain the IP address or host name of the host from where the session was initiated
  • Inactivity/Expiration Support
  • can be prolonged via a touch() method to keep them 'alive' if desired
  • Transparent Web Use
  • can use Shiro sessions in existing web applications and you
  • don't need to change any of your existing web cod
  • Can be used for SSO
  • easily stored in any data source
  • can be
  • 'shared'
  • across applications if needed
  • 'poor man's SSO'
  • simple sign-on experience since the shared session can retain authentication state
  • interface-based and implemented with POJOs
  • allows you to easily configure all session components with any JavaBeans-compatible configuration format, like JSON, YAML
  • easily extend
  • customize session management functionality
  • session data can be easily stored in any number of data sources
  • easily clustered using any of the readily-available networked caching products
  • no matter what container you deploy to, your sessions will be clustered the same way
  • No need for container-specific configuration!
  • Shiro sessions can be 'shared' across various client technologies
  • listen for these events and react to them for custom application behavior
  • SecurityUtils.getSubject()
  • currentUser.getSession()
  • If the Subject already has a Session, the boolean argument is ignored and the Session is returned immediately
  • If the Subject does not yet have a Session and the create boolean argument is true,
  • a new session will be created
  • and returned.
  • If the Subject does not yet have a Session and the create boolean argument is false, a new session will not be created and null is returned.
  • Suject.getSession(boolean create)
  • method functions the same way as the
  • HttpServletRequest.getSession(boolean create) method:
    • kuni katsuya
kuni katsuya

Terminology | Apache Shiro - 0 views

  • . Role
  • Role as simply a named collection of Permissions
  • This is a more concrete definition than the implicit one used by many applications
  • ...4 more annotations...
  • Permission
  • A Permission is only a statement of behavior, nothing more.
  • a statement that describes raw functionality in an application and nothing more
  • define only "What" the application can do
kuni katsuya

WildcardPermission (Apache Shiro 1.2.1 API) - 0 views

  • first token is the
  • domain
  • second token is the
  • ...7 more annotations...
  • action b
  • eing performed
  • boolean implies(Permission p)
  • Returns true if this current instance
  • implies all the functionality and/or resource access described by the specified Permission argument
  • false otherwise
  • current instance must be exactly equal to or a superset of the functionalty and/or resource access described by the given Permission argument
  •  
    "first token is the"
kuni katsuya

Permission (Apache Shiro 1.2.1 API) - 0 views

  • A Permission represents the ability to perform an action or access a resource. A Permission is the most granular, or atomic, unit in a system's security policy and is the cornerstone upon which fine-grained security models are built.
  • a Permission instance only represents functionality or access - it does not grant it
  • permissions are immutable and reflect an application's raw functionality
  • ...4 more annotations...
  • because Permissions represent raw functionality and only change when the application's source code changes, they are immutable at runtime - they represent 'what' the system can do
  • by transitive association, the user 'has' the permissions in their roles
  • all Permission checks are relegated to Realm implementations, and only those implementations really determine how a user 'has' a permission or not
  • Realm could use the semantics described here, or it could utilize some other mechanism entirely
kuni katsuya

Authorization | Apache Shiro - 0 views

  • PermissionResolver
  • use the PermissionResolver to convert the string into a Permission instance, and perform the check that way
  • All Shiro Realm implementations default to an internal
  • ...26 more annotations...
  • WildcardPermissionResolver
  • which assumes Shiro's
  • WildcardPermission
  • String format.
  • Authorization Sequence
  • what happens inside Shiro whenever an authorization call is made.
  • invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission*
  • securityManager implements the org.apache.shiro.authz.Authorizer interface
  • delegates to the application's SecurityManager by calling the securityManager's nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants
  • relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer's respective hasRole*, checkRole*, isPermitted*, or checkPermission* method
  • Realm's own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called
  • Authorization Sequence
  • Authorization Sequence
  • Authorization Sequence
  • Implicit Roles:
    • kuni katsuya
       
      BAD! do not use. prefer explicit (see below)
  • implies a set of behaviors (i.e. permissions) based on a role name only
  • Excplict Roles
  • named collection of actual permission statements
  • your realm is what will tell Shiro whether or not roles or permissions exist
  • Each Realm interaction functions as follows:
  • key difference with a RolePermissionResolver however is that the input String is a role name, and not a permission string.
  • Configuring a global RolePermissionResolver
  • RolePermissionResolver has the ability to represent Permission instances needed by a Realm to perform permission checks.
  • translate a role name into a concrete set of Permission instances
  • globalRolePermissionResolver = com.foo.bar.authz.MyPermissionResolver ... securityManager.authorizer.rolePermissionResolver = $globalRolePermissionResolver
  • shiro.ini
kuni katsuya

DomainPermission (Apache Shiro 1.2.1 API) - 0 views

  • used as a base class for JPA/Hibernate persisted permissions that wish to store the parts of the permission string in separate columns (e.g. 'domain', 'actions' and 'targets' columns)
kuni katsuya

Shiro User - Shiro in CDI/JPA2/JSF2 project - 1 views

  • CDI, JPA2 and JSF2
  • Apache Shiro
  • JpaRealm
  • ...10 more annotations...
  • Entity Beans in combination with an EntityManager
  • use CDI to inject the EntityManager into my JpaRealm
  • JpaRealm is not container managed but is instantiated by Shiro
  • delegate your JpaRealm into @Stateless EJB, which can @Inject EntityManager
  • JpaRealm
  • @PersistenceContext   private EntityManager entityManager;
  • EnvironmentLoaderListener
  • found the cause
  • Instead of configuring the ShiroFilter in my web.xml I had the IniShiroFilter configured. The IniShiroFilter creates a new SecurityManager from the ini file. This new SecurityManager didn't know about the realm I've added in my EnvironmentLoader, so it didn't have any realms.
  • I replaced it with the ShiroFilter in my web.xml and all seems to be working now with my CdiEnvironmentLoaderListener.
kuni katsuya

How to get EntityManager in a Apache Shiro Realm | OpenShift by Red Hat - 0 views

kuni katsuya

Shiro Developer - Role "Nesting" or "Inheriting" and RolePermissionResolvers - 0 views

  • Shiro support the concept of role inheritance ­ roleA inherits permissions from roleB
  • A given realm knows only its roles, but my application understands the mapping of roles to permissions (or nested roles).  I have a single RolePermissionResolver that ties permissions to roles
  • Example: My security Manager: https://github.com/sonatype/security/blob/master/security-system/src/main/java/org/sonatype/security/DefaultRealmSecurityManager.java#L63
  • ...1 more annotation...
  • My RolePermissionResolver https://github.com/sonatype/security/blob/master/security-realms/security-xml-realm/src/main/java/org/sonatype/security/realms/XmlRolePermissionResolver.java#L47
1 - 20 of 61 Next › Last »
Showing 20 items per page