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

Managing Project Permissions - JIRA 5.1 - Atlassian Documentation - Confluence - 0 views

confluence.atlassian.com/...Managing+Project+Permissions

security authorization Project Permission PermissionScheme example Jira

shared by kuni katsuya on 01 Sep 12 - No Cached
  • Project permissions can be granted to:
  • Individual usersGroupsProject rolesIssue roles such as 'Reporter', 'Project Lead' and 'Current Assignee''Anyone' (e.g. to allow anonymous access)A (multi-)user picker custom field.A (multi-)group picker custom field. This can either be an actual group picker custom field, or a (multi-)select-list whose values are group names.
  • Many other permissions are dependent on this permission
    • kuni katsuya
      kuni katsuya on 01 Sep 12
       
      example of dependencies *between* permissions. eg, in this case, work-on-issues permission 'needs' browse-projects permission could be expressed as a permission hierarchy where if work-on-issues permission is granted, means/implies that user already has browse-projects permission (w-o-i perm 'subsumes' b-p perm) might imply permission hierarchy
  • ...8 more annotations...
  • Permission Schemes
  • A permission scheme is a set of
  • user/group/role
  • assignments for the project permissions
  • Every project has a permission scheme
  • One permission scheme can be associated with multiple projects
  • Permission schemes prevent having to set up permissions individually for every project
  • it can be applied to all projects that have the same type of access requirements
kuni katsuya

Managing Project Permissions - JIRA Latest - Atlassian Documentation - Confluence - 0 views

confluence.atlassian.com/...Managing+Project+Permissions

security authorization PermissionScheme example Jira

shared by kuni katsuya on 01 Sep 12 - No Cached
  • Permission Schemes
  • A permission scheme is a set of
  • user/group/role
  • ...7 more annotations...
  • assignments for the project permissions
  • Every project has a permission scheme
  • One permission scheme can be associated with multiple projects
  • access rights
  • Permission schemes prevent having to set up permissions individually for every project
  • Once a permission scheme is set up
  • it can be applied to all projects that have the same type of access requirements
kuni katsuya

Seam Framework - Home - 0 views

seamframework.org/...Home

JBoss Seam Weld CDI ApacheDeltaSpike

shared by kuni katsuya on 01 Sep 12 - No Cached
  • How do Seam, Weld and CDI relate to each other?
  • CDI is a JCP specification included in Java EE Weld is the reference implementation of CDI Seam 3 is a set of modules which extend CDI to provide functionality beyond that offered by Java EE 6
  • Seam 3 is a superset of JSR-299
  • ...6 more annotations...
  • Think of JSR-299 as the core of Seam 3 - it's the basic programming model for your application components, and for the built-in components that make up the Seam framework
  • Seam 3 is implemented as a set of portable extensions, or modules
  • run in any environment which supports JSR-299 (including any Java EE 6 environment).
  • BPM integration, Seam Security, Drools integration, RESTeasy integration, PDF and email templates, Excel generation, etc
  • 2.0.0.Final End of 2012 Full specification compliance
  • Weld 2
kuni katsuya

Seam Framework - Home - 0 views

seamframework.org/Weld

JBoss Seam Weld CDI ApacheDeltaSpike

shared by kuni katsuya on 01 Sep 12 - Cached
  • How do Seam, Weld and CDI relate to each other?
kuni katsuya

The Future Of JBoss Seam And Apache DeltaSpike - 0 views

www.infoq.com/...seam-deltaspike

JBoss Seam ApacheDeltaSpike

shared by kuni katsuya on 01 Sep 12 - No Cached
  • The Future Of JBoss Seam And Apache DeltaSpike
  • Apache DeltaSpike (currently in incubation) is a set of extensions on Java CDI (Contexts and Dependency Injection)
  • Apr 11, 2012
  • ...2 more annotations...
  • We have no intention of releasing Seam 4
  • eventual aim is to migrate all of Seam 3 and MyFaces CODI to DeltaSpike
kuni katsuya

Threats - salesforce.com - 0 views

trust.salesforce.com/...best_practices

security policy BestPractices salesforce.com

shared by kuni katsuya on 01 Sep 12 - No Cached
  • Security Best Practices Webinar for All Salesforce.com Customers
  • Designate a security contact within your organization so that salesforce.com can more effectively communicate with you
  • Consider using other two-factor authentication techniques
  • ...14 more annotations...
  • activate IP range restrictions
  • Implement IP Restrictions in Salesforce.com
  • Two-Factor Authentication
  • second-level authorization, including requiring secure IT tokens
  • does not protect against “man-in-the-middle” attacks, where messages are intercepted
  • applications that may be integrated with salesforce.com are not protected by two-factor authentication
  • Strengthen Password Policies
    • kuni katsuya
      kuni katsuya on 01 Sep 12
       
      salesforce.com password policies: - password expiry period - password history (reuse) enforcement - minimum password length - password complexity requirement - forgotten password hint question requirement
  • Require Secure Sessions
  • mandating that all sessions are encrypted and secure
  • Decrease Session Timeout Thresholds
  • Identify a Primary Security Contact
  • identify a person in your company who is responsible for application security
  • should have a thorough understanding of your security policies
  • single point of contact for salesforce.com
kuni katsuya

JAAS Reference Guide - 0 views

docs.oracle.com/...JAASRefGuide.html

JavaAuthenticationAndAuthorizationService JAAS java security authentication authorization reference guide documentation

shared by kuni katsuya on 31 Aug 12 - No Cached
  • JavaTM Authentication and Authorization Service (JAAS) Reference Guide
  • Common Classes Subject Principals Credentials
  • Authentication Classes and Interfaces
  • ...7 more annotations...
  • Authorization Classes Policy AuthPermission PrivateCredentialPermission
  • Subject
  • Principals
  • Credentials
  • Authorization Classes
  • Policy
  • AuthPermission
kuni katsuya

Principle of least privilege - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/...Principle_of_least_privilege

security models LeastPrivilege authorization

shared by kuni katsuya on 31 Aug 12 - Cached
  • Principle of least privilege
  • requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program depending on the subject) must be able to
  • access only the information and resources that are necessary for its legitimate purpose
kuni katsuya

Access control - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/...Access_control

security models authentication authorization

shared by kuni katsuya on 31 Aug 12 - No Cached
  • Computer security
  • authentication, authorization and audit
  • In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects
  • ...39 more annotations...
  • Principle of least privilege
  • object-capability model, any software entity can potentially act as both a subject and object
  • Access control models used by current systems tend to fall into one of two classes:
  • those based on capabilities
  • those based on access control lists (ACLs)
  • Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject)
  • identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in; authorization determines what a subject can do; accountability identifies what a subject (or all subjects associated with a user) did.
  • Authorization determines what a subject can do on the system
  • Authorization
  • Access control models
  • categorized as either discretionary or non-discretionary
  • three most widely recognized models are
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Role Based Access Control (RBAC)
  • Attribute-based access control
  • Discretionary access control
  • Discretionary access control (DAC) is a policy determined by the owner of an object. The owner decides who is allowed to access the object and what privileges they have.
  • Every object in the system has an owner
  • access policy for an object is determined by its owner
  • DAC systems, each object's initial owner is the subject that caused it to be created
  • Mandatory access control
  • Mandatory access control refers to allowing access to a resource
  • if and only if rules exist
  • that allow a given user to access the resource
  • Management is often simplified (over what can be required) if the information can be protected using
  • hierarchical access control
  • or by implementing sensitivity labels.
  • Sensitivity labels
  • A subject's sensitivity label specifies its
  • level of trust
  • level of trust required for access
  • subject must have a sensitivity level equal to or higher than the requested object
  • Role-based access control
  • Role-based access control (RBAC) is an
  • access policy
  • determined by the system
  • not the owner
  • Access control
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
« First ‹ Previous 601 - 620 of 1268 Next › Last »
Showing 20▼ items per page