Skip to main content

Home/ SoftwareEngineering/ Contents contributed and discussions participated by kuni katsuya

Contents contributed and discussions participated by kuni katsuya

Simple Middle Filter: All | Bookmarks | Topics
kuni katsuya

Admin Guide - JBoss AS 7.1 - Project Documentation Editor - 0 views

docs.jboss.org/...Admin+Guide

jbossas7 DataSource deployment documentation

shared by kuni katsuya on 07 Aug 12 - No Cached
  • Deployment of -ds.xml files
  • Starting with JBoss Application Server 7.1.0.Final you have the ability to deploy a -ds.xml file following the schema: http://docs.jboss.org/ironjacamar/schema/datasources_1_1.xsd It is mandatory to use a reference to an already deployed / defined <driver> entry.
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

The New RBAC: Resource-Based Access Control | Stormpath - 0 views

www.stormpath.com/...-resource-based-access-control

RBAC Shiro authorization

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

How To Deal With Interfaces In Java EE 6 (or no more Impl) : Adam Bien's Weblog - 0 views

www.adam-bien.com/...how_to_deal_with_interfaces

CodingStandards

shared by kuni katsuya on 04 Aug 12 - No Cached
  • How To Deal With Interfaces In Java EE 6 (or no more Impl)
  • In Java EE 6 interfaces became absolutely optional. Neither in EJB 3.1, nor CDI / JSR-330 you need interfaces. You can inject classes directly. They will be still proxied, so all aspects like persistence, transactions, interceptors, decorators are still available. So you are no more forced to implement interfaces by the container
  • used for: Strategy Pattern: there are already several implementations of an algorithm or concept Layering: there is a clear need to hide e.g. an ugly implementation of a legacy framework API (not very common): you have to expose a API, which gets implemented by SPI (e.g. JDBC)
  • ...4 more annotations...
  • If you introduce interfaces intentionally - and not as a general rule, you will considerably reduce the number of files. Your code becomes easier to understand and so maintain
  • Even for decoupling purposes, interfaces are no more needed
  • "Contract First", "Coding To Interfaces" or "Decoupling"
  • is not a reason to introduce an interface for everything
« First ‹ Previous 781 - 800 of 1268 Next › Last »
Showing 20▼ items per page