Skip to main content

Home/ SoftwareEngineering/ Group items tagged Realm

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Realm (Apache Shiro :: Core 1.1.0 API) - 0 views

127.0.0.1/...Realm.html

security ApacheShiro Realm authentication authorization user Role Permission

shared by kuni katsuya on 03 Sep 12 - No Cached
  • Interface Realm
  • AuthenticatingRealm
  • AuthorizingRealm
  • ...7 more annotations...
  • JdbcRealm
  • A Realm is a security component that can access application-specific security entities such as users, roles, and permissions to determine authentication and authorization operations
  • security-specific DAOs
  • If for some reason you don't want your Realm implementation to perform authentication duties, you should override the supports(org.apache.shiro.authc.AuthenticationToken) method to always return false
  • does not require you to implement or extend any User, Group or Role interfaces or classes
  • Shiro tries to maintain a non-intrusive development philosophy
  • Most users will not implement the Realm interface directly, but will extend one of the subclasses, AuthenticatingRealm or AuthorizingRealm, greatly reducing the effort requird to implement a Realm from scratch
kuni katsuya

This is Stuff: Apache Shiro Part 2 - Realms, Database and PGP Certificates - 0 views

meri-stuff.blogspot.ca/...art-2-realms-database-and.html

security ApacheShiro Realm database

shared by kuni katsuya on 09 Aug 12 - No Cached
  • Apache Shiro Part 2 - Realms, Database and PGP Certificates
  • move user account data to database
  • give users an option to authenticate themselves via PGP certificates
  • ...9 more annotations...
  • log in options: log in with user name/password and log in with certificate
  • how to create custom realm and how to handle multi-realm scenario
  • account credentials and access rights are stored in database. Stored passwords are hashed and salted.
  • Authorization
  • If the realm wishes to do also authorization, it has to implement Authorizer interface. Each Authorizer method takes principal as parameter and checks either role(s) or permission(s)
  • Permissions are supplied either as strings or as permission objects
  • use WildcardPermissionResolver to convert strings into permission objects
  • connect application to database and create tables to store all user account data
  • replace IniRealm with realm able to read from database and salt passwords.
kuni katsuya

Architecture | Apache Shiro - 0 views

shiro.apache.org/architecture.html

apache shiro architecture

shared by kuni katsuya on 15 Aug 12 - No Cached
  • Realm is essentially a security-specific DAO
  • 3 primary concepts:
  • Subject
  • ...51 more annotations...
  • SecurityManager
  • Realms
  • High-Level Overview
  • Subject
  • essentially a security specific 'view' of the the currently executing user
  • Subject
  • instances are all bound to (and require) a
  • SecurityManager
  • When you interact with a Subject, those interactions translate to subject-specific interactions with the SecurityManager
  • SecurityManager
  • 'umbrella’ object that coordinates its internal security components that together form an object graph
  • Realms
  • ‘connector’ between Shiro and your
  • application’s security data
  • Shiro looks up many of these things from one or more Realms configured for an application
  • Subject
  • SecurityManager
  • Authenticator
  • Authorizer
  • component responsible determining users' access control in the application
  • if a user is allowed to do something or not
  • SessionManager
  • knows how to create and manage user
  • Session
  • lifecycles
  • Shiro has the ability to natively manage user Sessions in any environment, even if there is no Web/Servlet or EJB container available
  • Shiro will use
  • an existing session mechanism
  • if available, (e.g. Servlet Container)
  • if there isn't one, such as in a standalone application or non-web environment, it will use its
  • built-in enterprise session management
  • SessionDAO
  • exists to allow any datasource to be used to
  • persist sessions
  • SessionDAO
  • performs Session persistence (CRUD) operations on behalf of the SessionManager
  • allows any data store to be plugged in to the Session Management infrastructure
  • CacheManager
  • creates and manages Cache instance lifecycles used by other Shiro components
  • improve performance while using these data source
  • Cryptography
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • Realms
  • Realms
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
kuni katsuya

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

shiro-developer.582600.n2.nabble.com/issionResolvers-td5858003.html

ApacheShiro security permission inheritance

shared by kuni katsuya on 29 Aug 12 - No Cached
  • 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
kuni katsuya

AuthorizingRealm (Apache Shiro 1.2.1 API) - 0 views

shiro.apache.org/...AuthorizingRealm.html

security ApacheShiro authorization AuthorizingRealm realm

shared by kuni katsuya on 09 Sep 12 - No Cached
  • perform all role and permission checks automatically
  • getAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) method returns an AuthorizationInfo
  • subclasses do not have to write this logic
  • ...11 more annotations...
  • If caching is enabled and if any authorization data for an account is changed at runtime, such as adding or removing roles and/or permissions, the subclass implementation should clear the cached AuthorizationInfo for that account via the
  • clearCachedAuthorizationInfo method
  • getAuthorizationInfo
  • AuthorizingRealm
  • AuthorizationInfo getAuthorizationInfo(PrincipalCollection principals)
  • Returns an account's authorization-specific information for the specified principals, or null if no account could be found
  • This implementation obtains the actual AuthorizationInfo object
  • from the subclass's implementation of doGetAuthorizationInfo
  • and then caches it for efficient reuse if caching is enabled
  • clearCachedAuthorizationInfo(PrincipalCollection principals)
  • Clears out the AuthorizationInfo cache entry for the specified account.
kuni katsuya

JdbcRealm (Apache Shiro :: Core 1.1.0 API) - 0 views

127.0.0.1/...JdbcRealm.html

security ApacheShiro Realm JdbcRealm

shared by kuni katsuya on 03 Sep 12 - No Cached
  • Class JdbcRealm
  • Realm that allows authentication and authorization via JDBC calls
  • subclassed and the appropriate methods overridden. (usually doGetAuthenticationInfo(org.apache.shiro.authc.AuthenticationToken), getRoleNamesForUser(java.sql.Connection,String), and/or getPermissions(java.sql.Connection,String,java.util.Collection)
kuni katsuya

AuthorizationInfo (Apache Shiro :: Core 1.1.0 API) - 0 views

127.0.0.1/...AuthorizationInfo.html

security ApacheShiro authorization AuthorizationInfo

shared by kuni katsuya on 03 Sep 12 - No Cached
  • Interface AuthorizationInfo
  • AuthorizationInfo represents a single Subject's stored authorization data (roles, permissions, etc) used during authorization (access control) checks only
  • Roles are represented as a Collection of Strings (Collection<String>)
  • ...3 more annotations...
  • Permissions are provided in two ways: A Collection of Strings, where each String can usually be converted into Permission objects by a Realm's PermissionResolver A Collection of Permission objects
  • most Realms store both sets of data for a Subject
  • a Realm implementation to utilize an implementation of the Account interface instead, which is a convenience interface that combines both AuthenticationInfo and AuthorizationInfo
kuni katsuya

Realm | Apache Shiro - 0 views

shiro.apache.org/realm.html

Shiro Realm

shared by kuni katsuya on 09 Aug 12 - No Cached
  • A Realm is a component that can access application-specific security data such as users, roles, and permissions. The Realm translates this application-specific data into a format that Shiro understands so Shiro can in turn provide a single easy-to-understand Subject programming API no matter how many data sources exist or how application-specific your data might be.
  • A Realm is essentially a security-specific DAO
kuni katsuya

Application Security With Apache Shiro - 0 views

www.infoq.com/...apache-shiro

security ApacheShiro

shared by kuni katsuya on 08 Aug 12 - No Cached
  • previously known as the JSecurity project
  • The word Subject is a security term that basically means "the currently executing user"
  • Core Concepts: Subject, SecurityManager, and Realms
  • ...12 more annotations...
  • Subject
  • 'Subject' can mean a human being, but also a 3rd party process, daemon account, or anything similar. It simply means 'the thing that is currently interacting with the software'
  • Subject currentUser = SecurityUtils.getSubject();
  • SecurityManager
  • SecurityManager manages security operations for all users
  • Realms
  • Realm acts as the ‘bridge’ or ‘connector’ between Shiro and your application’s security data. That is, when it comes time to actually interact with security-related data like user accounts to perform authentication (login) and authorization (access control), Shiro looks up many of these things from one or more Realms configured for an application.
  • Realm is essentially a security-specific DAO
  • Shiro provides out-of-the-box Realms to connect to a number of security data sources (aka directories) such as LDAP, relational databases (JDBC), text configuration sources like INI and properties files, and more
  • Authorization
  • A permission is a raw statement of functionality, for example ‘open a door’, ‘create a blog entry’, ‘delete the ‘jsmith’ user’, etc. By having permissions reflect your application’s raw functionality, you only need to change permission checks when you change your application’s functionality. In turn, you can assign permissions to roles or to users as necessary at runtime.
  • “Run As” support for assuming the identity of another Subject
kuni katsuya

Permission (Apache Shiro 1.2.1 API) - 0 views

shiro.apache.org/...Permission.html

ApacheShiro permission

shared by kuni katsuya on 29 Aug 12 - No Cached
  • 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

JdbcRealm (Apache Shiro 1.2.1 API) - 0 views

shiro.apache.org/...JdbcRealm.html

ApacheShiro security jdbc authentication authorization JdbcRealm javadoc

shared by kuni katsuya on 03 Sep 12 - No Cached
  • JdbcRealm
  • Realm that allows authentication and authorization via JDBC calls
  • this class can be subclassed and the appropriate methods overridden. (usually doGetAuthenticationInfo(org.apache.shiro.authc.AuthenticationToken), getRoleNamesForUser(java.sql.Connection,String), and/or getPermissions(java.sql.Connection,String,java.util.Collection)
kuni katsuya

Authorization | Apache Shiro - 0 views

shiro.apache.org/authorization.html

ApacheShiro authorization RBAC Role Permission Subject

shared by kuni katsuya on 31 Aug 12 - No Cached
  • 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
      kuni katsuya on 23 Sep 12
       
      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

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

openshift.redhat.com/...anager-in-a-apache-shiro-realm

ApacheShiro EntityManager Realm PersistenceContext

shared by kuni katsuya on 29 Aug 12 - No Cached
kuni katsuya

AuthorizingRealm (Apache Shiro :: Core 1.1.0 API) - 0 views

127.0.0.1/...AuthorizingRealm.html

security ApacheShiro Realm AuthorizingRealm authorization

shared by kuni katsuya on 03 Sep 12 - No Cached
  • Class AuthorizingRealm
  • An AuthorizingRealm extends the AuthenticatingRealm's capabilities by adding Authorization (access control) support
  • perform all role and permission checks automatically (and subclasses do not have to write this logic) as long as the getAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) method returns an AuthorizationInfo
  • ...3 more annotations...
  • AuthorizationInfo getAuthorizationInfo(PrincipalCollection principals)
  • Returns an account's authorization-specific information for the specified principals, or null if no account could be found
  • automatically perform access control checks for the corresponding Subject
kuni katsuya

Permissions | Apache Shiro - 0 views

shiro.apache.org/permissions.html

security Shiro permissions authorization

shared by kuni katsuya on 07 Aug 12 - No Cached
  • Permission as a statement that defines an explicit behavior or action
  • lowest-level constructs in security polices
  • explicitly define only "what" the application can do
  • ...69 more annotations...
  • do not at all describe "who" is able to perform the action(s)
  • Multiple Parts
  • Wildcard Permissions support the concept of multiple levels or parts. For example, you could restructure the previous simple example by granting a user the permission printer:query
  • Multiple Values Each part can contain multiple values. So instead of granting the user both the "printer:print" and "printer:query" permissions, you could simply grant them one: printer:print,query
  • All Values What if you wanted to grant a user all values in a particular part? It would be more convenient to do this than to have to manually list every value. Again, based on the wildcard character, we can do this. If the printer domain had 3 possible actions (query, print, and manage), this: printer:query,print,manage
  • simply becomes this: printer:*
  • Using the wildcard in this way scales better than explicitly listing actions since, if you added a new action to the application later, you don't need to update the permissions that use the wildcard character in that part.
  • Finally, it is also possible to use the wildcard token in any part of a wildcard permission string. For example, if you wanted to grant a user the "view" action across all domains (not just printers), you could grant this: *:view Then any permission check for "foo:view" would return true
  • Instance-Level Access Control
  • instance-level Access Control Lists
  • Checking Permissions
  • SecurityUtils.getSubject().isPermitted("printer:print:lp7200")
  • printer:*:*
  • all actions on a single printer
  • printer:*:lp7200
    • kuni katsuya
      kuni katsuya on 03 Sep 12
       
      note: wildcard * usage for 'actions' part
  • missing parts imply that the user has access to all values corresponding to that part
  • printer:print is equivalent to printer:print:*
  • Missing Parts
  • rule of thumb is to
  • use the most specific permission string possible
  • when performing permission checks
  • first part is the
  • domain
    • kuni katsuya
      kuni katsuya on 03 Sep 12
       
      aka 'resource'
  • that is being operated on (printer)
  • second part is the
  • action
  • (query) being performed
  • There is no limit to the number of parts that can be used
  • three parts - the first is the
  • domain
  • the second is the
  • action(s)
  • third is the
  • instance(s)
  • allow access to
  • all actions
  • all printers
  • can only leave off parts from the end of the string
  • Performance Considerations
  • runtime implication logic must execute for
  • each assigned Permission
  • implicitly using Shiro's default
  • WildcardPermission
  • which executes the necessary implication logic
  • When using permission strings like the ones shown above, you're
  • Shiro's default behavior for Realm
  • for every permission check
  • all of the permissions assigned to that user
  • need to be checked individually for implication
  • as the number of permissions assigned to a user or their roles or groups increase, the time to perform the check will necessarily increase
  • If a Realm implementor has a
  • more efficient way of checking permissions and performing this implication logic
  • Realm isPermitted* method implementations
  • should implement that as part of their
  • implies
  • user:*:12345
  • user:update:12345
  • printer
  • implies
  • printer:print
  • Implication, not Equality
  • permission
  • checks
  • are evaluated by
  • implication
  • logic - not equality checks
  • the former implies the latter
  • superset of functionality
  • implication logic can be executed at runtime
kuni katsuya

Apache Shiro JDBC Realm « Mehmet Celiksoy's Weblog - 0 views

blog.pinateknoloji.com/shiro-jdbc-realm

security ApacheShiro JdbcRealm

shared by kuni katsuya on 08 Aug 12 - No Cached
  • how you create a JDBC realm
  • Apache Shiro
  •  doGetAuthenticationInfo(AuthenticationToken token) 
  • ...1 more annotation...
  •  getRoleNamesForUser(Connection conn, String username) 
kuni katsuya

java - Getting confused with Apache Shiro and Custom Authorizing Realms - Stack Overflow - 0 views

stackoverflow.com/...-and-custom-authorizing-realms

security ApacheShiro realm RealmSecurityManager SecurityManager authorization AuthorizationInfo

shared by kuni katsuya on 22 Sep 12 - No Cached
  • getRealms()
  • RealmSecurityManager
  • authorization is effectively disabled due to the default doGetAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) implementation returning null
kuni katsuya

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

shiro-user.582556.n2.nabble.com/A2-JSF2-project-td7577437.html

ApacheShiro JpaRealm CDI

shared by kuni katsuya on 29 Aug 12 - No Cached
  • 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.
1 - 20 of 22 Next ›
Showing 20▼ items per page