Skip to main content

Home/ SoftwareEngineering/ Group items tagged security

Rss Feed Group items tagged

kuni katsuya

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

  • 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

Appendix C. Spring Security Dependencies - 0 views

  • Spring Security Dependencies
  • This appendix provides a reference of the modules in Spring Security and the additional dependencies that they require in order to function in a running application
  • C.1 spring-security-coreThe core module must be included in any project using Spring Security.
  • ...8 more annotations...
  • DependencyVersionDescriptionaopalliance1.0Required for method security implementation.
  • spring-aop Method security is based on Spring AOP
  • spring-beans Required for Spring configuration
  • spring-expression Required for expression-based method security (optional)
  • spring-jdbc Required if using a database to store user data (optional).
  • spring-tx Required if using a database to store user data (optional).
  • C.6 spring-security-aclThe ACL module.
  • spring-jdbc Required if you are using the default JDBC-based AclService (optional if you implement your own).spring-tx Required if you are using the default JDBC-based AclService (optional if you implement your own).
kuni katsuya

Threats - salesforce.com - 0 views

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

JBoss Developer Framework - 0 views

  • jta-crash-rec Crash Recovery, JTA Uses Java Transaction API and JBoss Transactions to demonstrate recovery of a crashed transaction
  • jts-distributed-crash-rec JTS Demonstrates recovery of distributed crashed components
  • cdi-injection CDI Demonstrates the use of CDI 1.0 Injection and Qualifiers with JSF as the front-end client.
  • ...13 more annotations...
  • bean-validation JPA, Bean Validation Shows how to use Arquillian to test Bean Validation
  • ejb-security Security, EJB Shows how to use Java EE Declarative Security to Control Access to EJB 3
  • payment-cdi-event CDI Demonstrates how to use CDI 1.0 Events
  • richfaces-validation RichFaces Demonstrates RichFaces and bean validation
  • ejb-in-war JSF, WAR, EJB Packages an EJB JAR in a WAR
  • greeter EJB, JPA, JSF, JTA, CDI Demonstrates the use of CDI 1.0, JPA 2.0, JTA 1.1, EJB 3.1 and JSF 2.0
  • helloworld-mdb EJB, MDB, JMS Demonstrates the use of JMS 1.1 and EJB 3.1 Message-Driven Bean
  • helloworld-rs JAX-RS, CDI Demonstrates the use of CDI 1.0 and JAX-RS
  • kitchensink BV, EJB, JAX-RS, JPA, JPA, JSF, CDI
  • servlet-async CDI, EJB, Servlet Demonstrates CDI, plus asynchronous Servlets and EJBs
  • servlet-security Security, Servlet Demonstrates how to use Java EE declarative security to control access to Servlet 3
  • shopping-cart EJB Demonstrates a stateful session bean
  • tasks Arquillian, JPA Demonstrates testing JPA using Arquillian
kuni katsuya

Spring Security - Features - 0 views

  • Domain object instance security: In many applications it's desirable to define Access Control Lists (ACLs) for individual domain object instances. We provide a comprehensive ACL package with features including integer bit masking, permission inheritance (including blocking), an optimized JDBC-backed ACL repository, caching and a pluggable, interface-driven design.
  • OpenID Support: the web's emerging single sign-on standard (supported by Google, IBM, Sun, Yahoo and others) is also supported in Spring Security
  • Easy integration with existing databases: Our implementations have been designed to make it easy to use your existing authentication schema and data (without modification). Of course, you can also provide your own Data Access Object if you wish. Password encoding: Of course, passwords in your authentication repository need not be in plain text. We support both SHA and MD5 encoding, and also pluggable "salt" providers to maximise password security.
  • ...5 more annotations...
  • Caching: Spring Security optionally integrates with Spring's Ehcache factory. This flexibility means your database (or other authentication repository) is not repeatedly queried for authentication information when using Spring Security with stateless applications.
  • Run-as replacement: The system fully supports temporarily replacing the authenticated principal for the duration of the web request or bean invocation. This enables you to build public-facing object tiers with different security configurations than your backend objects.
  • Tag library support: Your JSP files can use our taglib to ensure that protected content like links and messages are only displayed to users holding the appropriate granted authorities. The taglib also fully integrates with Spring Security's ACL services, and obtaining extra information about the logged-in principal.
  • User Provisioning APIs: Support for groups, hierarchical roles and a user management API, which all combine to reduce development time and significantly improve system administration.
  • Enterprise-wide single sign on using CAS 3: Spring Security integrates with JA-SIG's open source Central Authentication Service (CAS)
kuni katsuya

Architecture | Apache Shiro - 0 views

  • 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

Application Security With Apache Shiro - 0 views

  • 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

Chapter 16. Extensibilty - 0 views

  • 16.2. Writing a Security Service
  • login(Object credentials)
  • authorize(AbstractSecurityContext context)
  • ...20 more annotations...
  •  logout() 
  • An implementation of this interface must be thread safe
  • If authorization fails, either because the user is not logged in or because it doesn't have required rights, it must throw an appropriate org.granite.messaging.service.security.SecurityServiceException.
  • Writing a Security Service
  • SecurityService interface
  • nothing to do with a true Flex destination
  • only one instance of this service is used in the entire web-app and will be called by concurrent threads
  • configure
  • login
  • This method is called upon each and every service method call invocations (RemoteObject) or subscribe/publish actions (Consumer/Producer). When used with RemoteObjects, the authorize method is responsible for checking security, calling the service method, and returning the corresponding result.
  • authorize
  • logout
  • handleSecurityException
  • default implementation of this method in AbstractSecurityService is to do nothing
  • security services are not exposed to outside calls
  • configure
  • login
  • authorize
  • logout
  • handleSecurityException
kuni katsuya

Chapter 10. Integration with CDI - 0 views

  • Chapter 10. Integration with CDI
  • GraniteDS provides out-of-the-box integration with CDI via the Tide API
  • GraniteDS also integrates with container security for authentication and role-based authorization
  • ...37 more annotations...
  • always have to include this library in either WEB-INF/lib
  • support for CDI is included in the library granite-cdi.jar
  • 10.1. Configuration with Servlet 3 On Servlet 3 compliant containers, GraniteDS can use the new APIs to automatically register its own servlets and filters and thus does not need any particular configuration in web.xml. This automatic setup is triggered when GraniteDS finds a class annotated with @FlexFilter in one of the application archives:
  • @FlexFilter(configProvider=CDIConfigProvider.class) public class GraniteConfig { }  
  • list of annotation names that enable remote access to CDI beans
  • ConfigProvider
  • override these values by setting them in the annotation properties
  • tide=true,         type="cdi",         factoryClass=CDIServiceFactory.class,         tideInterfaces={Identity.class}
  • @FlexFilter declaration will setup an AMF processor for the specified url pattern
  • tideAnnotations
  • defines suitable default values
  • @TideEnabled
  • @RemoteDestination
  • always declared by default
  • tideInterfaces
  • tideRoles
  • exceptionConverters
  • amf3MessageInterceptor
  • 10.3.2. Typesafe Remoting with Dependency Injection
  • It is possible to benefit from even more type safety by using the annotation [Inject] instead of In. When using this annotation, the full class name is used to find the target bean in the CDI context instead of the bean name.
  • Security
  • integration between the client RemoteObject credentials and the server-side container security
  • client-side component named
  • identity
  • API to define runtime authorization checks on the Flex UI
  • login()
  • logout()
  • login(username, password, loginResult, loginFault)
  • logout()
  • bindable property
  • represents the current authentication state
  • loggedIn
  • identity.loggedIn 
  • integrated with server-side role-based security
  • identity.hasRole('admin')
  • clear the security cache manually with
  • identity.clearSecurityCache()
kuni katsuya

Chapter 9. Integration with Seam 2.2 - 0 views

  • 9.2.6. Integration with Seam Security
  • When not using the Seam native setup, you have to manually configure the integration of Seam Security in granite-config.xml.
  • <granite-config>    ...    <!--     ! Use Seam 2.1+ based security service.     !-->     <security type="org.granite.seam21.security.Seam21SecurityService"/> </granite-config>
kuni katsuya

Session Management Cheat Sheet - OWASP - 0 views

  • Session Management Cheat Sheet
  • should not be extremely descriptive nor offer unnecessary details
  • change the default session ID name of the web development framework to a generic name
  • ...50 more annotations...
  • length must be at least 128 bits (16 bytes)
  • Session ID Length
  • Session ID Name Fingerprinting
  • Session ID Properties
  • Session ID Entropy
  • must be unpredictable (random enough) to prevent guessing attacks
  • good PRNG (Pseudo Random Number Generator) must be used
  • must provide at least 64 bits of entropy
  • Session ID Content (or Value)
  • content (or value) must be meaningless
  • identifier on the client side
  • meaning and business or application logic associated to the session ID must be stored on the server side
  • session objects or in a session management database or repository
  • create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
  • Session Management Implementation
  • defines the exchange mechanism that will be used between the user and the web application to share and continuously exchange the session ID
  • token expiration date and time
  • This is one of the reasons why cookies (RFCs 2109 & 2965 & 6265 [1]) are one of the most extensively used session ID exchange mechanisms, offering advanced capabilities not available in other methods
  • Transport Layer Security
  • use an encrypted HTTPS (SSL/TLS) connection for the entire web session
  • not only for the authentication
  • process where the user credentials are exchanged.
  • “Secure” cookie attribute
  • must be used to ensure the session ID is only exchanged through an encrypted channel
  • never switch a given session from HTTP to HTTPS, or viceversa
  • should not mix encrypted and unencrypted contents (HTML pages, images, CSS, Javascript files, etc) on the same host (or even domain - see the “domain” cookie attribute)
  • should not offer public unencrypted contents and private encrypted contents from the same host
  • www.example.com over HTTP (unencrypted) for the public contents
  • secure.example.com over HTTPS (encrypted) for the private and sensitive contents (where sessions exist)
  • only has port TCP/80 open
  • only has port TCP/443 open
  • “HTTP Strict Transport Security (HSTS)” (previously called STS) to enforce HTTPS connections.
  • Secure Attribute
  • instructs web browsers to only send the cookie through an encrypted HTTPS (SSL/TLS) connection
  • HttpOnly Attribute
  • instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object
  • Domain and Path Attributes
  • instructs web browsers to only send the cookie to the specified domain and all subdomains
  • “Domain” cookie attribute
  • “Path” cookie attribute
  • instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application
  • vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com
  • Expire and Max-Age Attributes
  • “Max-Age”
  • “Expires” attributes
  • it will be considered a
  • persistent cookie
  • and will be stored on disk by the web browser based until the expiration time
  • use non-persistent cookies for session management purposes, so that the session ID does not remain on the web client cache for long periods of time, from where an attacker can obtain it.
  • Session ID Life Cycle
kuni katsuya

Subject | Apache Shiro - 0 views

  • Understanding Subjects in Apache Shiro
  • 'Subject'
  • is just a security term that means a
  • ...8 more annotations...
  • security-specific 'view'
  • of an application user
  • Subject instance represents both security state and operations for
  • a single application user
  • in the security world, the term 'Subject' is actually the recognized nomenclature
  • Subject currentUser = SecurityUtils.getSubject();
  • obtain the currently executing Subject by using org.apache.shiro.SecurityUtils:
  • Subject based on user data associated with current thread or incoming request.
kuni katsuya

Extending the security interceptor for Weld/JSF2 @ Blog of Adam Warski - 1 views

  • Extending the security interceptor for Weld/JSF2
  • simple security interceptor, which checks conditions defined
  • using EL expressions
kuni katsuya

Java Persistence/Auditing and Security - Wikibooks, open books for an open world - 0 views

  • Use a common database user id, and manage auditing and security in the application
  • managed in the application by having an application user, and a single shared database user
  • adding a AUDIT_USER and AUDIT_TIMESTAMP column to all of the audited tables and auditUser and auditTimestamp field to all of the audited objects
  • ...5 more annotations...
  • When the application inserts or updates an object, it will set these fields and they will be stored in the database. JPA events could also be used to record the audit information, or to write to a separate audit table.
  • Example AuditedObject class
  • @MappedSuperclass public Class AuditedObject {
  • @Column("AUDIT_USER"); protected String auditUser; @Column("AUDIT_TIMESTAMP"); protected Calendar auditTimestamp;
  • @PrePersist @PreUpdate public void updateAuditInfo() { setAuditUser((String)AuditedObject.currentUser.get()); setAuditTimestamp(Calendar.getInstance()); }
  •  
    Use a common database user id, and manage auditing and security in the application
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

Apache Camel: Shiro Security - 0 views

  • Shiro Security Component
  • Available as of Camel 2.5
kuni katsuya

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

  • 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

Securing Data Access - 0 views

kuni katsuya

Spring vs Java EE Web Dev: Using Shiro for Authorization via CDI Interceptors then Easi... - 1 views

  • Using Shiro for Authorization via CDI Interceptors then Easily Test with Arquillian Did you know Apache Shiro is an easy-to-use security
  • @Secured @NamedResource("contact")
  • Interceptors will be ignored by CDI container unless it is listed in beans.xml
  • ...2 more annotations...
  • Tells the security interceptor to check the permission using "contact" as the resource name, not "contactmanager" inflected from the class name ContactManager
  • @NamedResource("contact")
1 - 20 of 148 Next › Last »
Showing 20 items per page