Skip to main content

Home/ SoftwareEngineering/ Group items tagged permission

Rss Feed Group items tagged

kuni katsuya

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

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

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

Ending a Sprint - GreenHopper 6.1 - Atlassian Documentation - Confluence - 0 views

  • Ending a Sprint
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • Once a sprint is closed, you cannot re-open it
  • ...11 more annotations...
  • You can release the sprint as a version if you wish
  • In the Completed Issues section of the Sprint Report, just click View in Issue Navigator
  • use JIRA's Bulk Edit to assign all of the issues to the relevant version
  • Note that you will not be able to do this if your "Done" column sets an issue's status to "Closed", as issues are not editable once they are "Closed"
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • need to have the JIRA 'Project Administrator' permission in the project(s) whose issues are included in the sprint.
  • Ending a Sprint
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

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

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

  • 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

Security Module Drafts - Apache DeltaSpike - Apache Software Foundation - 0 views

  • Authorization
  • Impersonalization
    • kuni katsuya
       
      impersonation
  • authenticates โ€œas a userโ€ or access application imitating his identity - without knowing his password
  • ...36 more annotations...
  • elements of the user interface are displayed to the user based on the user's privilege level
  • assign permissions to individual objects within the applicationโ€™s business domain
    • kuni katsuya
       
      individual objects == instances
  • Permissions
  • Permissions assigned to user for a given resource in the tree are inherited by other resources
  • Permissions are inherited
  • persist user, group and role information in database. JPA implementation is his dream
  • Security Module Drafts
  • Identity
  • interface Identity
  • login()
  • logout()
  • getUser()
  • Events LoggedInEvent LoginFailedEvent AlreadyLoggedInEvent PreLoggedOutEvent PostLoggedOutEvent PreAuthenticateEvent PostAuthenticateEvent
  • Object level permission
  • Grant or revoke permissions
  • Group management
  • User/Identity management
  • identity.hasRole
  • identity.hasPermission
  • Permissions model
  • Identity Management (IDM)
  • User, Group and Role
  • Events
  • hooks for common IDM or Security operations
  • Audit and logging for permission and IDM related changes
  • Event API.
  • Impersonalization
  • Impersonalization
  • control which elements of the user interface are displayed to the user based on their assigned permissions
  • ask for permission
  • without need to obtain object from DB
  • String resourceId
  • structure of resources
  • more advanced security resolution mechanisms
  • Rules based engine
  • external services - XACML
kuni katsuya

Java Authorization Guide | Apache Shiro - 0 views

  • Java Authorization Guide with Apache Shiro
  • Levels of permission granularity
  • specify an actions (open, read, delete, etc)
  • ...18 more annotations...
  • resource (door, file, customer record, etc)
  • define a permission to any depth
  • Resource Level
  • Instance Level
  • Attribute Level
  • instance of a resource
  • attribute of an instance or resource
  • Permissions Defined
  • Permissions represent what can be done in your application
  • A well formed permission describes a resource types and what actions are possible when you interact with those resources
  • Roles Defined
  • Roles are effectively a collection of permissions
  • Explicit Roles
  • An explicit role has permissions explicitly assigned to it and therefore is an explicit collection of permissions
  • Implicit Roles
    • kuni katsuya
       
      do not use!!!
  • Annotation Authorization
  • @RequiresPermissions(โ€œaccount:createโ€)โ€
  • Permission Check
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
kuni katsuya

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

  • 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

Seam - Contextual Components - 0 views

  • 15.6. Authorization
  • Seam Security is built around the premise of users being granted roles and/or permissions, allowing them to perform operations that may not otherwise be permissible for users without the necessary security privileges
  • 15.6.1. Core concepts
  • ...15 more annotations...
  • 15.6.1.1. What is a role? A role is a group, or type, of user that may have been granted certain privileges for performing one or more specific actions within an application
  • used to create logical groups of users for the convenient assignment of specific application privileges
  • 15.6.1.2. What is a permission? A permission is a privilege (sometimes once-off) for performing a single, specific action. It is entirely possible to build an application using nothing but permissions, however roles offer a higher level of convenience when granting privileges to groups of users
  • consisting of three "aspects";
  • a target
  • an action
  • a recipient
  • An empty @Restrict implies a permission check of componentName:methodName
  • implied permission required to call the delete() method is account:delete
  • equivalent of this would be to write @Restrict("#{s:hasPermission('account','delete')}")
  • @Restrict annotation may reference any objects that exist within a Seam context. This is extremely useful when performing permission checks for a specific object instance.
  • selectedAccount
  • selectedAccount
  •  Identity.instance().checkRestriction
  • If the expression specified doesn't evaluate to true, either if the user is not logged in, a NotLoggedInException exception is thrown or if the user is logged in, an AuthorizationException exception is thrown.
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

cygwin permissions bug on Windows 8 ยป Vineet Gupta - 0 views

  • cygwin permissions bug on Windows 8
  • Permissions 0660 for '/home/Vineet/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /home/Vineet/.ssh/id_rsa Permission denied (publickey).
  • quick fix is to change the group on all existing entries:
  • ...12 more annotations...
  • chgrp -R Users ~/.ssh
  • 1) Check the group Id of the โ€˜Usersโ€™ group in /etc/group
  • -rw-------
  • Hereโ€™s how you can fix the root cause:
  • chmod 600 ~/.ssh/id_rsa
  • cat /etc/group | egrep '^Users:' | cut -f3 -d':'
  • value was 545
  • 2) Check the primary group for your user in /etc/passwd
  • cat /etc/passwd | egrep '^Vineet:' | cut -f4 -d':'
  • value was 513 (which was the value for the โ€˜Noneโ€™ group in /etc/group)
  • 3) Change this value to the one found in the previous step for โ€˜Usersโ€™ (545 in this example)
  • 4) Exit cygwin and restart
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

TH01-EP03-US004 - Property Mgmt, Edit Location & Directions, Content Mgmt - Projects - ... - 0 views

  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • ...18 more annotations...
  • Property Mgmt
  • Property Mgmt
  • Property Mgmt
  • As a user
    • kuni katsuya
       
      with what granted roles? from which organization?
  • ability to see
    • kuni katsuya
       
      permissions required: retrieve these resource types
  • Location Type
  • Description
  • Airports
  • belonging to other organizations
    • kuni katsuya
       
      content (license) owned by organization different than user's
  • clone this information
    • kuni katsuya
       
      clone = retrieve, then create ie. required permissions: {retrieve,create:}
  • have the rights
    • kuni katsuya
       
      generally speaking, there can be a few independent but overlapping mechanism that will control who is allowed to do what with content: 1. any subject's access to the content itself can be controlled via authorization rules (ie. required vs granted permissions) enforced via system-wide resource-based access control 2. content licensors (~content owners) can restrict the usage of their content by: * whom - ie. content licensee (legally/commercially represented by an organization) * how - eg. reuse as unmodified, create derivatives, composite, redistribute, etc * where - ie. distribution channels their content can be used (eg. only on hotel's vbrochure site, but not in any ids/gds channels) * when - temporal restrictions may limit scope of content license grant by: start, end, duration, season, etc 3. content licensees can further filter or funnel content available to them (resulting from a combination of license granted to them and access control) based on their own criteria (eg. generate a templated hotel presentation only if: at least 1 textual description, 5 photos and 1 video for a hotel is available with a license to combine them (composite content)
  • see how other organizations describe the property
    • kuni katsuya
       
      permission required: retrieve hotel descriptive content(?) owned by independent organization
  • Property Mgmt
  • which textual information
  • displayed
    • kuni katsuya
       
      displayed where? on specific channels?
  • ECM will ask user to confirm that the user has rights to use that content
    • kuni katsuya
       
      if ecm/vfml is to manage content licensing as a third party between organizations (content licensors & licensees) shouldn't ecm *know* if the user('s organization) has rights to use the content in question? is this question posed to the user (with required explicit acknowledgement) purely to absolve vfml from liability issues that may result from licensing disagreements?
  • propertyโ€™s
    • kuni katsuya
       
      this being the user's (organization's) 'version'or 'view'of the hotel, since this user normally wouldn't/shouldn't be granted permissions to replace content for a hotel on a different organization's 'view'or 'version' of the same hotel
  • to see the userโ€™s original content
    • kuni katsuya
       
      this implies that *at least* one version of such (temporarily) replaceable content needs to be managed/maintaned to allow reverting what if, deliberately, ignorantly or maliciously, a user replaces the same piece of--textual or any type, really--content for this hotel n times? will all n versions be required to be managed as an undo history? the user's ''original content'' might have been version 1, but equally might have been 1 mean: - previous version of the content, regardless of which user - initial version of that content attached to the hotel regardless of which user created/updated it and ignoring which organization owns it?, or, -
kuni katsuya

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

  • Interface RolePermissionResolver
  • RolePermissionResolver resolves a String value and converts it into a Collection of Permission instances
  • resolve the roles into permissions
    • kuni katsuya
       
      Role is just a collection of Permissions
kuni katsuya

AuthorizationInfo (Apache Shiro 1.2.1 API) - 0 views

  • AuthorizationInfo
  • represents a single Subject's stored authorization data (roles, permissions, etc)
  • Roles are represented as a Collection of Strings
  • ...4 more annotations...
  • Permissions are provided in two ways:
  • Collection of Strings
  • Collection of Permission objects
  • represent the total aggregate collection of permissions
kuni katsuya

Access Tokens and Types - Facebook Developers - 0 views

  • Access Tokens and Types
  • Access Tokens
  • random string that provides temporary, secure access to Facebook APIs
  • ...27 more annotations...
  • token identifies a User, App or Page session and provides information about granted permissions
  • Types
  • User Access
  • generated in the login flow when a
  • Facebook Pages
  • on behalf of a user
  • use this token to perform API calls
  • Page Access
  • used to
  • manage
  • user grants permissions to an app
  • user who is the
  • App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app
  • must grant an extended permission called
  • manage_pages
  • use this type of token to make API calls
  • on behalf of a page
  • unique to each page, admin and app
  • App Access
  • useful to modify app settings, create and manage test users or read App Insights data
  • use app tokens to publish or delete content
  • on behalf of a user
  • unique to each app
  • Security Best Practices
  • extremely important that an App Secret is not compromised
  • Page admin
  • App Access Tokens should only be used directly from your app's servers in order to provide the best security
kuni katsuya

Login for Server-side Apps - Facebook Developers - 0 views

  • compare it to the same state variable stored client-side in the session
    • kuni katsuya
       
      cross-site request forgery defense mechanism
  • If the user decided to decline to authorize your app
  • YOUR_REDIRECT_URI
  • ...38 more annotations...
  • error_reason=user_denied
  • Handling Revoked Permissions to see how best to proceed
  • Step 6. Exchange the code for an Access Token
  • exchange it for a User access token that can then be used to make API requests
  • /oauth/access_token
  • server-side request to the following OAuth endpoint:
  • client_secret
  • code=CODE_GENERATED_BY_FACEBOOK
  • body of the response
  • access_token
  • USER_ACCESS_TOKEN
  • persist this User access token in your database or in a session variable
  • must have the same base domain as that specified in the App Domain property of your app's settings
  • URL of the form https://apps.facebook.com/YOUR_APP_NAMESPACE
  • scope=user_birthday,read_stream
  • Step 4. Add Permissions to Login Dialog request
  • comma-separated list of any of the Permissions available
  • Step 5. Handle the response from the Login Dialog
  • Step 5. Handle the response from the Login Dialog
  • Step 5. Handle the response from the Login Dialog
  • Step 5. Handle the response from the Login Dialog
  • YOUR_REDIRECT_URI
  • Step 3. Redirect the user to the Login Dialog
  • Login for Server-side Apps
  • Login for Server-side Apps
  • Login for Server-side Apps
  • Login for Server-side Apps
  • Login for Server-side Apps
  • Login for Server-side Apps
  • way to authenticate users in situations where the use of client-side Javascript is not appropriate.
  • Login for Server-side Apps
  • received an access token for them and can make API calls on their behalf
  • Step 5. Handle the response from the Login Dialog
  • include CSRF protection using the state parameter
  • if the user has authorized the app, they will be redirected to:
  • YOUR_REDIRECT_URI
  • code=CODE_GENERATED_BY_FACEBOOK
  • redirect_uri as the same URL that redirect the user to the Login Dialog
kuni katsuya

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

  • 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.
1 - 20 of 46 Next › Last »
Showing 20 items per page