Skip to main content

Home/ SoftwareEngineering/ Group items tagged Shiro

Rss Feed Group items tagged

kuni katsuya

Permissions | Apache Shiro - 0 views

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

  • how you create a JDBC realm
  • Apache Shiro
  •  doGetAuthenticationInfo(AuthenticationToken token) 
  • ...1 more annotation...
  •  getRoleNamesForUser(Connection conn, String username) 
kuni katsuya

HTTP Authentication and Security with Apache Shiro | Xebia Blog - 0 views

  • Spring Security
  • However, it is tied to the Spring technology and the size of the library — more than 10 JAR of dependencies
  •  
    "its "
kuni katsuya

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

  • getRealms()
  • RealmSecurityManager
  • authorization is effectively disabled due to the default doGetAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) implementation returning null
kuni katsuya

Grails - user - Can Spring Security OR Shiro Enable Fine Grained Hierarchical Permissions? - 0 views

  • one option would be to embed the hierarchy of locations in the permission strings
  • since you can have any number of elements separated by colons
  • Another option would be to create your own Permission instances and implement the isPermitted() method such that it delegates to Location.isIn(Location) for permission checks
  • ...2 more annotations...
  • associate permissions with a particular domain instance AND all children of that instance.
  • associate a single rule/ACL Entry that says Sally has full hierarchical permission over France
« First ‹ Previous 41 - 60 of 78 Next ›
Showing 20 items per page