OACC (Object ACcess Control) is an advanced Java Application Security Framework

Related tags

Security oacc-core
Overview

OACC Java Application Security Framework

What is OACC?

OACC - pronounced [oak] - is a fully featured API to both enforce and manage your application's authentication and authorization needs.

In a nutshell, OACC provides permission-based authorization services and allows your application to enforce security by answering the question:

Is entity 'A' allowed to perform action 'p' on entity 'B'?

Features

  • Fully implemented API
    All the functionality to manage your application's security model, out of the box.

  • Single access-control paradigm
    Always operate at the resource level. Manage permissions exclusively between resources.

  • Flexible security model
    Secure any operation between your domain objects and the actors on them.

  • Permission delegation
    Authorize subjects to delegate their permissions to others with GRANT OPTIONS.

  • Identity delegation
    Authorize an authenticated subject to securely "impersonate" another subject.

  • Efficient query methods
    Find resources by permission with efficient symmetric query methods.

Learn more about all of OACC's authorization and authentication features on the Features page of the project website.

License

OACC is open source software released under the commercial friendly Apache License, Version 2.0.

Supported Environments

OACC persists all security relationships in database tables and currently supports the following databases:

  • IBM DB2 10.5
  • Microsoft SQL Server 12.0 (2014)
  • Oracle 11g R2
  • PostgreSQL 9.3
  • HSQLDB 2.3
  • MySQL 5.6 / MariaDB 10.0
  • SQLite 3.8

OACC is compatible with Java™ SE 7 (Java™ version 1.7.0), or higher.

Get Started

The easiest way to include the latest OACC release into your project is to declare the following Maven coordinates as a dependency in your POM file:

<dependency>
    <groupId>com.acciente.oacc</groupId>
    <artifactId>acciente-oacc</artifactId>
    <version>2.0.0</version>
</dependency>

To install, configure and initialize the OACC database, please refer to the Get Started Tutorial on the project website.

The SecureTodo sample application illustrates how to integrate OACC into a Java application and how to address several real-world authorization scenarios. The writeup is also available in the Github repository that contains the full source code.

Documentation

You can find more information about OACC, including the latest Javadocs, releases, and tutorials on the project website: oaccframework.org.

About Acciente

Acciente, LLC is a software company located in Scottsdale, Arizona specializing in systems architecture and software design for medium to large scale software projects.

Comments
  • define multiple roles for a user with oacc

    define multiple roles for a user with oacc

    In the feature list of OACC I find the following text "... OACC supports full RBAC ...". My question is: How I can define users with multiple roles?

    Following I will describe my current scenario:

    • there are multiple hospitals
    • different specialist (Radiodiagnosis, Nuclear medicine, Surgery, Pathologic anatomy, Radiation therapy, Oncology, Physical rehabilitation, Psychology, Genetic) are in every hospital (thats are the users; requesting objects)
    • a user may have several specializations
    • different patient are in every hospital (thats are my controlled objects)
    • a patient have some data or documents (some of them are also controlled objects)

    The following permissions we must define:

    • specialists of a hospital can see the full patient data from their hospital
    • specialists from other hospitals can see only some patient data or anonymised data
    • some specialist (Radiodiagnosis, Pathologic anatomy) can process image analysis functions on images from patients
    • other specialist can only see the result of the image analysis

    Can anybody help me? Thank you!

    question permission modeling 
    opened by audersch 7
  • Seperate resources

    Seperate resources

    Hallo,

    I would like to know If I can implement the following use case with OACC and if my idea how to implement this is the right approach:

    I have different resources of the resource class "device", I need to group then and separate them hierarchically and I have a resource class "users" which are going to have different permissions per group device.

    Group A should contain all devices. Group B should contain a subset of devices. I would also like to split group B in different subsets. Called group B1 and B2.

    I would like to add to each device group users, which will have different permissions for each group. A user in group A should have permissions for all devices, i.e. to edit and view devices in all groups. Users in group B should have permissions for all devices in group B and the subgroups of B.

    Can I implement this scenario with domains and subdomains with oacc?

    I would create a parent domain with child domains. Then, I would create device resources in the parent domain and create user resources in each domain.

    Is it possible to "inherit" devices from the parent to the subdomain? Is it also possible, to create user roles which are going to define different permissions for a single domain?

    question permission modeling 
    opened by WerVbn 5
  • Adding MANIFEST.MF Main-Class

    Adding MANIFEST.MF Main-Class

    Hi,

    I think it could be useful to add a main-class manifest attribute, that points to SQLAccessControlSystemInitializer, so it will ease the command line syntax...

    Thanks & best regards, Sebastien

    enhancement 
    opened by sebfz1 3
  • Update getting-started-tutorial.html

    Update getting-started-tutorial.html

    Hi,

    The getting-started-tutorial.html is not up-to-date, the correct package in rc4 is com.acciente.oacc.sql.SQLAccessControlSystemInitializer

    $ java com.acciente.oacc.SQLAccessControlSystemInitializer -dburl=<db-url> \
    >  -dbuser=<db-user> \
    >  -dbpwd=<db-password> \
    >  -oaccsystempwd=<OACC-root-password> \
    >  [ -dbschema=<db-schema> ]   # [optional - omit if no database schema was created]
    

    Thanks, Sebastien.

    documentation 
    opened by sebfz1 3
  • A timing channel in PasswordCredentials.java

    A timing channel in PasswordCredentials.java

    Current password comparison violates the "constant-time" discipline which could lead to a timing attack: https://github.com/acciente/oacc-core/blob/master/src/main/java/com/acciente/oacc/PasswordCredentials.java#L66

    For more information about timing attack, please refer to: https://codahale.com/a-lesson-in-timing-attacks/

    invalid 
    opened by fredfeng 2
  • How to initialize OACC, when using SQLite?

    How to initialize OACC, when using SQLite?

    The getting started tutorial mentions that OACC needs to be initialized with SQLAccessControlSystemInitializer. Though this fails for SQLite because it has no concept of a database schema. And under RDBMS specific-notes, it says to pass null for schemaName but there's no way to do so via the command line. Even if -dbschema is not provided SQLAccessControlSystemInitializer defaults to TEST_OACC (see here).

    For -dbschema="":

    Exception in thread "main" java.lang.IllegalArgumentException: Invalid database schema name - it can only consist of (optionally delimited) unicode word characters, or be null, but it was:
            at com.acciente.oacc.sql.internal.SchemaNameValidator.assertValid(SchemaNameValidator.java:74)
            at com.acciente.oacc.sql.internal.SQLAccessControlSystemInitializer.initializeOACC(SQLAccessControlSystemInitializer.java:34)
            at com.acciente.oacc.sql.SQLAccessControlSystemInitializer.initializeOACC(SQLAccessControlSystemInitializer.java:92)
            at com.acciente.oacc.sql.SQLAccessControlSystemInitializer.main(SQLAccessControlSystemInitializer.java:79)
    

    For -dbschema=:

    Exception in thread "main" java.lang.IllegalArgumentException: Invalid database schema name - it can only consist of (optionally delimited) unicode word characters, or be null, but it was:
            at com.acciente.oacc.sql.internal.SchemaNameValidator.assertValid(SchemaNameValidator.java:74)
            at com.acciente.oacc.sql.internal.SQLAccessControlSystemInitializer.initializeOACC(SQLAccessControlSystemInitializer.java:34)
            at com.acciente.oacc.sql.SQLAccessControlSystemInitializer.initializeOACC(SQLAccessControlSystemInitializer.java:92)
            at com.acciente.oacc.sql.SQLAccessControlSystemInitializer.main(SQLAccessControlSystemInitializer.java:79)
    
    bug 
    opened by smotti 2
  • Inheritance for permission targets?

    Inheritance for permission targets?

    This is more of a question than an issue.

    Consider an app where a user dynamically (i.e. at runtime) defines a "role" as a oacc resource with permissions for a specific target resource. The scope of such a role would be limited in something like a user-defined workflow. My understanding is that "user" resources can then be given the INHERIT built-in permission on the "role" to inherit permissions assigned to it. Assuming that is correct:

    a) is it possible to similarly apply some concept of inheritance to resources used as permission targets under the same scope without actually creating copies of the original permissions? Are resource classes or domains relevant here? b) would it be possible to implement custom business logic that allows resources to inherit different permission targets as described above during their lifecycle (i.e. based on some status or whatnot)?

    question permission modeling 
    opened by manosbatsis 2
  • Question - Can roles/perms can be inherited ?

    Question - Can roles/perms can be inherited ?

    Say if there are 2 users one with READ and another with WRITE permission. Then can the user with WRITE permission READ the given resource/document also?

    In addition to that, the secure-todo example is sharing items to another user hence giving the access to it. Can't we assign the same permissions to a new user with which an existing user created a resource and this new user can directly access this given the fact that both the users have same permissions? Is this possible.

    question 
    opened by thealchemistt 1
  • Resources.getInstance(LONG) returns resource, but no externalId

    Resources.getInstance(LONG) returns resource, but no externalId

    Resource resource = Resources.getInstance(91L); returns the desired resource, but not the externalId of the resource. This happens only, when a long parameter is passed to the method.

    resouce.getExternalId() returns null

    not a bug 
    opened by WerVbn 1
  • Compilation errors in test classes when imported in eclipse

    Compilation errors in test classes when imported in eclipse

    Compilation errors when importing the project in eclipse for two test classes TestSQLAccessControlContextFactory and TestSQLAccessControlSystemInitializer

    The above two classes are calling "com.ibm.icu.impl.Assert.fail" methods but it seems we need to replace this with "org.junit.Assert.fail" (and in pom we never have dependency to icu4j)

    bug 
    opened by mpujari 1
  • OACC on Maven Central

    OACC on Maven Central

    Hi

    I noticed a thread discussing on OACC on Maven Central (https://groups.google.com/forum/#!topic/oacc-users/8nL6JeC8Xc0)

    Just to create this issue to take note of the status.

    Regards Ian Lim

    opened by mallim 1
  • Relation/integration with OAuth 2.0 / OpenID Connect

    Relation/integration with OAuth 2.0 / OpenID Connect

    Can OACC work in context of OAuth 2.0 and OpenID Connect ?

    https://www.scottbrady91.com/OAuth/Delegation-Patterns-for-OAuth-20

    "OAuth is all about delegation. It allows a client application to ask resource owner (a user) for permission to access a protected resource (an HTTP API) on their behalf. It is a delegation protocol."

    Specifically, how would "delegation" work? Any reasons why it would clearly not make sense to use OACC as implementation ?

    question 
    opened by SemanticBeeng 0
  • Is spring integration supported/planned?

    Is spring integration supported/planned?

    Hello,

    It seems that OACC follows an interesting approach to seucirty and permissions management. Would it support spring integration out of the box? Correct me if i'm wrong and it is already supported, because i haven't digged enought into the framework yet.

    Thanks in advance

    question 
    opened by jarey 3
Releases(v2.0.0)
  • v2.0.0(Oct 12, 2018)

    Release date: 2018-10-11

    Summary of changes in this release:

    • fixes minor javadoc issue referencing a private field
    • updates version of bouncycastle dependency to latest
    • updates copyright notice to include 2018
    • removes all deprecated methods
    • fixes #48: adds correct reference to outer table in correlated subqueries for permission lookups by name
    • adds new authenticate() method that only takes credentials (it does not require an explicit Resource argument) to support authentication protocols with encrypted tokens that contain the necessary information to resolve the resource; Note that the built-in password-based authentication provider does not support token-based authentication, and that a custom provider must return the associated resource to the OACC context

    Summary of API changes:

    • *New feature* Support for token-based authentication
      • Prior to this release, OACC has required a Resource parameter to identify who is authenticating. Now OACC supports a method that only requires Credentials, for the case when an encrypted auth-token contains the information to resolve the resource to be authenticated.
    • removes all previously deprecated methods from rc.5 - rc.8

    Bug fixes:

    • fixes #48: adds correct reference to outer table in correlated subqueries for permission lookups by name

    Use the following dependency to include this release of OACC into your Maven project:

    <dependency>
      <groupId>com.acciente.oacc</groupId>
      <artifactId>acciente-oacc</artifactId>
      <version>2.0.0</version>
    </dependency>
    

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc.8(Jun 8, 2017)

    Release date: 2017-06-07

    Summary of changes in this release:

    • adds support for pluggable password encryptors to the built-in SQLPasswordAuthenticationProvider, and prefixes the password hash with an identifier for the encryptor settings that created the hash
    • adds a Jasypt-based password encryptor implementation with configurable digest parameters
    • adds an OpenBSD-based bcrypt password encryptor implementation
    • adds a transitioning password encryptor that can check existing passwords hashed with an old encryptor, but creates hashes with a new encryptor
    • deprecates old factory methods for SQLAccessControlContext that did not specify a SQLPasswordAuthenticationProvider
    • adds a PasswordEncryptor parameter to SQLAccessControlContext factory methods that did not already take a SQLPasswordAuthenticationProvider
    • SQLAccessControlSystemInitializer now requires a new -pwdencryptor command line argument
    • deprecates LegacyJasyptPasswordEncryptor (formerly known as StrongCleanablePasswordEncryptor)
    • renames CleanablePasswordEncryptor interface to PasswordEncryptor
    • replaces Jasypt-based Unicode text normalization with up-to-date (and backwards compatible) ICU4J implementation, and applies it across all password encryptors
    • fixes #31 - SQLAccessControlSystemInitializer command line tool now correctly accepts not specifying dbSchema
    • makes several command line arguments of SQLAccessControlSystemInitializer optional for databases that do not require them, and improves usage info
    • changes Resource's toString() to output a more accurate and future-proof representation
    • modifies toString() on all permission implementations for simplicity and consistency
    • adds equals() and hashCode() methods to the PasswordCredentials implementation
    • fixes acciente/oacc-db#3 - changes case of table identifiers in SQL statements to match the database setup scripts
    • refactors internal SQLAccessControlSystemInitializer to delegate to AuthenticationProvider and to use Credentials
    • updates SQLPasswordAuthenticationProvider's serialVersionUID due to serialization-incompatible structural changes
    • removes unused SQLDialect parameter in the SQLPasswordAuthenticationProvider constructors
    • removes the JUnit test suite classes to simplify running all tests, and removes obsolete test classes
    • improves Javadoc comments and fixes typos
    • updates dependencies to latest versions in pom.xml, and adds the PostgreSQL JDBC driver (test scope)
    • removes obsolete configuration of surefire plugin in pom.xml and updates licensing-related information
    • updates copyright notices

    Summary of API changes:

    • *New feature* Pluggable password encryptors
      • Prior to this release, OACC's built-in authentication provider used a Jasypt-based password hash. Now OACC supports configuring the password hashing scheme and provides two implementations of the PasswordEncryptor interface: Jasypt and BCrypt.
      • adds a Jasypt-based password encryptor implementation with configurable digest parameters
      • adds an OpenBSD-based bcrypt password encryptor implementation
      • adds a transitioning password encryptor that can check existing passwords hashed with an old encryptor, but creates hashes with a new encryptor
      • deprecates and moves StrongCleanablePasswordEncryptor to LegacyJasyptPasswordEncryptor
      • renames CleanablePasswordEncryptor interface to PasswordEncryptor
      • updates SQLPasswordAuthenticationProvider's serialVersionUID due to serialization-incompatible structural changes
      • adds new factory methods to SQLAccessControlContextFactory that take a PasswordEncryptor parameter
      • SQLAccessControlSystemInitializer now requires a new -pwdencryptor command line argument, but several command line arguments become optional for databases that do not require them
      • adds support to provide alternate resource identifier to createResource() with externalId String parameter
      • allows one-time setting of alternate resource identifier to an existing resource via the new setExternalId() method
      • adds externalId to Resource and modifies getId() to return Long instead of a primitive
    • changes Resource's toString() to output a more accurate and future-proof representation
    • modifies toString() on all permission implementations for simplicity and consistency
    • adds equals() and hashCode() methods to the PasswordCredentials implementation
    • *Deprecation* deprecates old factory methods for SQLAccessControlContext that did not specify a SQLPasswordAuthenticationProvider
    • *Deprecation* deprecates LegacyJasyptPasswordEncryptor (formerly known as StrongCleanablePasswordEncryptor)

    Bug fixes:

    • fixes #31 - SQLAccessControlSystemInitializer command line tool now allows not specifying the optional dbschema
    • fixes acciente/oacc-db#3 - changes case of table identifiers in SQL statements to match the database setup scripts

    Use the following dependency to include this release of OACC into your Maven project:

    <dependency>
      <groupId>com.acciente.oacc</groupId>
      <artifactId>acciente-oacc</artifactId>
      <version>2.0.0-rc.8</version>
    </dependency>
    

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc.7(Feb 16, 2016)

    Release date: 2016-02-15

    Summary of changes in this release:

    • refactors all permission factories to cache immutable permission objects
    • normalizes post create permission parameters to OACC's internal implementation in create permission factories
    • fixes #26 - replaced import statements in test classes that incorrectly had a dependency to the icu4j library
    • changes the type of the post-create permission field in create-permission implementations
    • adds database config properties for official mariaDB database drivers for testing
    • updates databaseName property to upper case in MySQL test configuration, to be consistent with the MySQL DDL scripts in oacc-db
    • updates test suite for the aforementioned changes
    • updates pom.xml to allow publishing release artifacts to the Maven Central Repository

    Summary of API changes:

    • Create-permission factory methods now normalize the post-create permission parameter to OACC's internal implementation and throw an IllegalArgumentException if the parameter was null

    Bug fixes:

    • fixes #26 - replaced import statements in test classes that incorrectly had a dependency to the icu4j library
    • fixes create-permission implementations to guarantee serializability

    Use the following dependency to include this release of OACC into your Maven project:

    <dependency>
      <groupId>com.acciente.oacc</groupId>
      <artifactId>acciente-oacc</artifactId>
      <version>2.0.0-rc.7</version>
    </dependency>
    

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc.6(Jan 12, 2016)

    Release date: 2016-01-11

    Summary of changes in this release:

    • adds serialVersionUIDs to all applicable classes
    • deprecates preSerialize() methods
    • validates dataSource or connection are not null
    • fixes a bug that could cause NullPointerException for equals() and hashCode() of OACC's Resource implementation
    • modifies getAuthenticatedResource() and getSessionResource() to return lazily-cached defensive copies of the session variables
    • validates that database schema names are either null or a single sequence of unicode word characters
    • updates test suite for the aforementioned changes
    • updates copyright notices

    Summary of API changes:

    • Improves serialization support
      • adds serialVersionUids to all applicable classes
      • unserializable fields are now marked transient
      • consistent usage of Serializable marker interface
    • Deprecation deprecates obsolete preSerialize() methods because unserializable fields are now marked transient

    Bug fixes:

    • fixes #23 - equals() and hashCode() of OACC's Resource implementation no longer can produce NullPointerException when resource was created without a resourceId

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.6-javadoc.jar(694.38 KB)
    acciente-oacc-2.0.0-rc.6-jdk1_7.jar(244.37 KB)
    acciente-oacc-2.0.0-rc.6-sources.jar(189.71 KB)
  • v2.0.0-rc.5(Nov 18, 2015)

    Release date: 2015-11-17

    Summary of changes in this release:

    • adds support for creating resources with an external id as an alternate resource identifier
    • adds externalId to Resource and modifies getId() to return Long instead of a primitive
    • adds support for all API methods that take a resource, to handle the alternate externalId identifier
    • resolves and validates resource references passed to the API
    • normalizes and validates permissions passed to the API
    • deprecates the getInstance() permission factory methods that take a boolean indicating the grant option and replaces them with dedicated getInstanceWithGrantOption() methods
    • deprecates withGrant in all permissions and replaces it with withGrantOption for clarity
    • refactors implementation to remove redundant map traversals and to extract duplicate code blocks
    • adds calls to close jdbc statements in tests where it was missing in several instances, and updates Oracle database config properties to use UCP datasource for the tests
    • updates test suite for the aforementioned changes

    Summary of API changes:

    • New feature External id as alternate resource reference
      • Prior to this release, OACC exported a single numerical resourceId as the minimal way of coupling, instead of importing a client value, so as to allow the most flexibility in how clients can integrate OACC into their application.
        Now OACC allows a client application to specify a single String representation of a globally unique externalId to create and reference resources, so that clients can avoid having to store the resourceId generated by OACC
      • adds support to provide alternate resource identifier to createResource() with externalId String parameter
      • allows one-time setting of alternate resource identifier to an existing resource via the new setExternalId() method
      • adds externalId to Resource and modifies getId() to return Long instead of a primitive
    • Deprecation deprecates withGrant in all permission objects and replaces it with withGrantOption for clarity
    • Deprecation deprecates the getInstance() permission factory methods that take a boolean to indicate the grant option and replaces them with dedicated getInstanceWithGrantOption() methods

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.5-javadoc.jar(686.05 KB)
    acciente-oacc-2.0.0-rc.5-jdk1_7.jar(239.44 KB)
    acciente-oacc-2.0.0-rc.5-sources.jar(183.31 KB)
  • v2.0.0-rc.4(Sep 30, 2015)

    Release date: 2015-09-29

    Summary of changes in this release:

    • adds implementation strategies to handle databases that do not support recursive queries or sequence generators
    • adds SQL dialect support for HSQLDB, MySQL/MariaDB, and SQLite
    • adds SQLProfile and replaces SQLDialect as the parameter to instantiate a SQLAccessControlContext
    • fixes a bug related to getting resources by permission, which didn't take domain-inherited SYSTEM permissions into account
    • updates test suite for the aforementioned changes and bug fixes

    Summary of API changes:

    • New feature Expanded database support
      • Prior to this release, OACC made use of certain database features (such as recursive CTEs to efficiently traverse the permission graph, and sequence generators to provide new IDs) that aren't supported in all database systems;
        Now OACC includes support for auto-incrementing identity columns and to allow non-recursive querying, which will allow persisting the permission graph in many more RDBMS implementations
      • Requires an instance of the new SQLProfile class instead of the SQLDialect enum when getting an AccessControlContext from the SQLAccessControlContextFactory, to account for the aforementioned database features supported by the underlying database system
      • Adds profiles for HSQLDB, MySQL and SQLite

    Bug fixes:

    • fixes #16 - getResourcesByPermission() and getResourcesByPermissionAndDomain() methods did not take into account global system permissions that are inherited from a domain

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.4-javadoc.jar(675.72 KB)
    acciente-oacc-2.0.0-rc.4-jdk1_7.jar(231.36 KB)
    acciente-oacc-2.0.0-rc.4-sources.jar(178.48 KB)
  • v2.0.0-rc.3(Jul 15, 2015)

    Release date: 2015-07-14

    Summary of changes in this release:

    • adds grant/revoke permission methods
    • adds methods to delete resources and domains
    • adds query authorization
    • adds set-based versions of methods that previously only accepted vararg permissions
    • removes methods that are overloaded with the session resource or its domain as the default accessor or target domain
    • modifies getEffectivePermission-methods to include permissions acquired implicitly via super-user privileges
    • modifies methods that take vararg permission arguments to validate that they don't contain identical duplicates
    • fortifies StrongCleanablePasswordEncryptor with checks for null arguments
    • fixes two bugs related to setting duplicate permission that differ in grant option, as described in more detail below
    • updates test suite for the aforementioned API changes
    • updates Javadoc comments with the aforementioned API changes

    Summary of API changes:

    • New feature Grant/Revoke permission methods
      • For more fine-grained control of permission assignment, OACC now also provides grant and revoke methods for each permission type, which allow to add or remove one (or more) permissions from the set of existing direct permissions, respectively
    • New feature Delete resources and domains
      • Adds new deleteResource() method that will perform a cascading delete of a resource from the security graph
      • Adds new deleteDomain() method that will delete a domain and any nested child domains
    • New feature Query authorization
      • Allows for control of which resources can be inquired about via new *QUERY system resource permission
      • All query methods now check if the session resource is authorized to query. This affects:
        • permission retrieval methods
        • permission verification methods
        • resource retrieval by permissions methods
    • Set-based versions for all vararg methods
      • All methods that take vararg permission parameters use a pattern to enforce a compile-time check that at least one permission parameter has been passed, which unfortunately doesn't allow for an elegant Collections-compatible way to call the method; for this reason such methods now also have a version that takes a Set of permissions instead of the vararg pattern
    • Overloaded method removal
      • Removes methods that are overloaded by defaulting the accessor resource or target domain based on the session resource, such as
        • permission assertion methods
        • has-permission methods
        • get-permission methods
        • createResource
        • getResourcesByResourcePermissions/-AndDomain
      • The only methods remaining in the OACC API overloaded for convenience' sake are those that accept permission parameters as Sets or as varargs
    • More consistent and comprehensive permission handling
      • The getResourcePermissionNames() method now includes any applicable system permissions in its result set
      • All getEffectivePermission-methods now explicitly include any permissions acquired implicitly via super-user privileges
    • Parameter validation
      • Modifies methods that take vararg permission arguments to validate that they don't contain identical duplicates. Note that this modification changes the behavior from previously silently ignoring such duplicates to now throwing an exception!

    Bug fixes:

    • fixes #15 - setDomainCreatePermissions() now checks for duplicate create permission with differing grant options to prevent a SQLException
    • fixes #14 - setResourceCreatePermissions() now checks for duplicate *CREATE permission with differing grant options to prevent a SQLException

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.3-javadoc.jar(441.33 KB)
    acciente-oacc-2.0.0-rc.3-jdk1_7.jar(156.81 KB)
    acciente-oacc-2.0.0-rc.3-sources.jar(121.04 KB)
  • v2.0.0-rc.2(Mar 24, 2015)

    Release date: 2015-03-23

    Summary of changes in this release:

    • replaces the checked AccessControlException with hierarchy of unchecked exceptions
    • enhances permission verification API with boolean has-permission methods and updates all verification methods to accept multiple permissions, as well as to consistently provide overloaded versions with optional accessorResource and/or domainName arguments
    • renames getResourcesByResourcePermissions() to getResourcesByResourcePermissionsAndDomain() when it takes a domainName argument
    • updates method signatures to always place domainName parameter directly after resourceClassName parameter, where applicable
    • updates resource getters (getResourcesByResourcePermissions and getAccessorResourcesByResourcePermissions) to accept multiple permissions
    • adds resource class and domain as arguments to AuthenticationProvider.validateCredentials() for more context
    • adds parameter validation to API methods to assert that accessor resource arguments reference an existing resource
    • refactors parameter validation in API methods to be slightly more consistent by validating in the order of the method signature
    • fixes several bugs, as described in more detail below
    • updates test suite for the aforementioned API changes
    • updates Javadoc comments with the aforementioned API changes

    Summary of API changes:

    • Exception handling
      • replaces the checked AccessControlException with more nuanced hierarchy of unchecked exceptions (including more structured and consistent exception messages)
    • Permission verification
      • changes the assert methods based on a redesign that makes them consistent with the effective permission getters: now assert methods for each type of permission are overloaded with optional accessor resource and/or domain name arguments
      • introduces new kind of permission verification method: the has-permission method, which returns a boolean instead of throwing an exception; there is a has-permission method as an alternative for each of the assert methods
      • updates the assert and has-permission methods to accept permissions as (one or more) varargs, instead of a just single permission
    • Method signatures
      • updates method signatures to always place domainName parameter directly after resourceClassName parameter, where applicable
      • updates resource getters (getResourcesByResourcePermissions and getAccessorResourcesByResourcePermissions) to accept permissions as (one or more) varargs, instead of just a single permission
      • renames the getResourcesByResourcePermissions-methods with a domain name argument to getResourcesByResourcePermissionsAndDomain, to distinguish them from the getResourcesByResourcePermissions-methods without a domain name argument, which return results across all domains
      • adds resource class and domain as arguments to AuthenticationProvider.validateCredentials() for more context
    • Parameter validation
      • adds parameter validation to API methods to assert that accessor resource arguments reference an existing resource
      • refactors method parameter validation to be slightly more consistent by validating in the order of the method signature

    Bug fixes:

    • fixes internal permission validation method to ensure RESET_CREDENTIALS and IMPERSONATE are only valid for authenticatable resource classes
    • fixes setResourcePermissions() to prevent an INHERIT cycle from a resource to itself
    • fixes createResource() to now assert session is authenticated when called without domain name arguments (because it will implicitly use the session resource domain in those cases)
    • fixes internal has-permission helper methods to remove redundant check for global permissions after checking effective permissions

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.2-javadoc.jar(443.39 KB)
    acciente-oacc-2.0.0-rc.2-jdk1_7.jar(138.87 KB)
    acciente-oacc-2.0.0-rc.2-sources.jar(107.61 KB)
  • v2.0.0-rc.1(Jan 10, 2015)

    Release date: 2015-01-09

    Summary of changes in this release:

    • adds new API methods to retrieve direct permissions
    • changes all permission classes to interfaces and moves factory methods to new permission factories
    • fixes several bugs, as described in more detail below
    • extends comprehensive test suite to essentially cover the entire API
    • adds checks to API methods to assert arguments are not null or blank
    • refines javaDoc comments
    • refactors internal codebase (i.e. not the public-facing API)
      • to be more consistent and descriptive in method and class names
      • to improve readability
    • updates copyright notices

    Summary of API changes:

    • in AccessControlContext, adds get-methods for direct permissions to provide round-trip symmetry with the set-methods (enhancement #13) - previously OACC only had getters for effective permissions.
      • getResourcePermissions()
      • getGlobalResourcePermissions()
      • getResourceCreatePermissions()
      • getDomainPermissions()
      • getDomainCreatePermissions()
    • changes all permission classes to interfaces and moves factory methods to the following newly added permission factories
      • ResourcePermissions
      • ResourceCreatePermissions
      • DomainPermissions
      • DomainCreatePermissions

    Bug fixes:

    • fixes overloaded getResourcesByResourcePermission() to check permissions to the accessor resource when the accessor resource is not identical to the session resource
    • fixes getResourcesByResourcePermission() to not check permissions to the accessor resource when it is identical to the session resource
    • fixes impersonate() to explicitly use the authenticated resource when checking permissions and to check for null arguments
    • fixes getDomainNameByResource() to not throw NullPointerException for non-existent resource references
    • fixes getResourceClassInfo() to not throw NullPointerException for non-existent resource class references
    • fixes #12 - assertResourcePermission() now takes withGrant attribute into account when asserting permission
    • fixes #11 - assertGlobalResourcePermission() now takes withGrant attribute into account when asserting permission
    • fixes #10 - assertPostCreateResourcePermission() now takes withGrant attribute into account when asserting permission
    • fixes #9 - setCredentials() now allows the authenticated resource to set its credentials without requiring explicit permissions
    • fixes getAccessorResourcesByResourcePermission() to be whitespace consistent
    • fixes getResourcePermissionNames() to be whitespace consistent
    • fixes assertPostCreateResourcePermission() to be whitespace consistent
    • fixes setGlobalResourcePermissions() to be whitespace consistent
    • fixes getEffectiveGlobalResourcePermissions() to be whitespace consistent
    • fixes getEffectiveResourceCreatePermissions() to be whitespace consistent
    • fixes getEffectiveDomainPermissions() to be whitespace consistent
    • fixes createDomain() for child domains to be whitespace consistent
    • fixes getResourcesByResourcePermission() to be whitespace consistent
    • fixes all effective permission getters to remove grant-equivalent duplicates from the result
    • fixes #8 - setDomainCreatePermissions() no longer checks grant permissions on permissions that are not being changed
    • fixes #7 - setDomainPermissions() no longer checks grant permissions on permissions that are not being changed
    • fixes #6 - setGlobalResourcePermissions() no longer checks grant permissions on permissions that are not being changed and correctly handles up/downgrade of permissions with grant
    • fixes #4 - setResourceCreatePermissions() no longer checks grant permissions on permissions that are not being changed and correctly handles up/downgrade of permissions with grant
    • fixes #5 - setResourceCreatePermissions() strictly validates requested create permissions against specified resource class
    • fixes #3 - setResourcePermissions() no longer checks grant permissions on permissions that are not being changed and correctly handles up/downgrade of permissions with grant
    • fixes #2 - setResourcePermissions() no longer checks grant permissions on permissions that are not being changed and only requires the granting privileges that are necessary
    • fixes #1 - getEffectiveResourcePermissions() now includes global and domain-inherited permissions

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-rc.1-javadoc.jar(399.36 KB)
    acciente-oacc-2.0.0-rc.1-jdk1_7.jar(128.58 KB)
    acciente-oacc-2.0.0-rc.1-sources.jar(95.83 KB)
  • v2.0.0-alpha.4(Jan 10, 2015)

    Summary of changes in this release:

    • pluggable authentication provider support
    • redesigned authentication API calls to use credentials instead of passwords
    • new extensible credentials interface to allow arbitrary authentication mechanisms
    • built-in authentication provider now uses char[] instead of String for passwords

    Summary of API (AccessControlContext) changes:

    • authenticate method now takes a Credentials instance instead of a password
    • new authenticate method to support authentication without providing credentials (for authentication provider that support it)
    • renames setResourcePassword() to setCredentials()
    • replaces createAuthenticatableResource() with overloaded createResource() methods

    Includes a built-in AuthenticationProvider that provides password-based authentication, so that clients have the option to use OACC without having to implement their own authentication mechanism. Note that any passwords handled by the built-in authentication provider now use char[] exclusively, instead of String.

    Bug fixes:

    • fixes a bug that caused AccessControlContext instances to not be serializable

    Corresponding oacc-db release: The version of the oacc-db database configuration scripts to be used with this release can be found here.

    Source code(tar.gz)
    Source code(zip)
    acciente-oacc-2.0.0-alpha.4-javadoc.jar(363.50 KB)
    acciente-oacc-2.0.0-alpha.4-jdk1_7.jar(111.06 KB)
    acciente-oacc-2.0.0-alpha.4-sources.jar(84.17 KB)
Spring-react-security - 🌶 Spring Security & React 🌶

Spring-react-security - ?? Spring Security & React ??

KimJunhan 2 Mar 28, 2022
PicketLink is a security framework for securing Java EE applications.

PicketLink http://picketlink.org Java EE Application Security Identity Management Federation Social REST Security Standard-based Security This reposit

PicketLink 92 Feb 21, 2022
Advanced Programming Final Project

Clash Royale Advanced Programming Final Project Clash Royale By Java July 2021 Requirements Java and JavaFx SDK MySQL Database Screenshots How to run

Ashkan Shakiba 12 Oct 11, 2022
Burp Extension for BFAC (Advanced Backup-File Artifacts Testing for Web-Applications)

BFAC - Burp Extension Burp Extension for BFAC (Advanced Backup-File Artifacts Testing for Web-Applications). What is BFAC - Burp Extension ? Backup fi

SEC-IT 18 Jul 16, 2022
Security engine for Java (authentication, authorization, multi frameworks): OAuth, CAS, SAML, OpenID Connect, LDAP, JWT...

pac4j is an easy and powerful security engine for Java to authenticate users, get their profiles and manage authorizations in order to secure web appl

PAC4J 2.2k Dec 30, 2022
A library for bypassing all of Java's security mechanisms, visibility checks, and encapsulation measures via the JNI API

Narcissus: thwart strong encapsulation in JDK 16+ Narcissus is a JNI native code library that provides a small subset of the Java reflection API, whil

ToolFactory 29 Nov 3, 2022
OAUTHScan is a Burp Suite Extension written in Java with the aim to provide some automatic security checks

OAUTHScan is a Burp Suite Extension written in Java with the aim to provide some automatic security checks, which could be useful during penetration testing on applications implementing OAUTHv2 and OpenID standards.

Maurizio S 163 Nov 29, 2022
Open Source Identity and Access Management For Modern Applications and Services

Keycloak Keycloak is an Open Source Identity and Access Management solution for modern Applications and Services. This repository contains the source

Keycloak 14.6k Jan 5, 2023
Spring Security

Spring Security Spring Security provides security services for the Spring IO Platform. Spring Security 5.0 requires Spring 5.0 as a minimum and also r

Spring 7.4k Jan 5, 2023
Employee Management System using Spring Boot, Spring Security, Thymeleaf and MySQL database.

Employee Management System Employee Management System using Spring Boot, Spring Security, Thymeleaf and MySQL database. YouTube Video Series Employee

Ramesh Fadatare 62 Jan 1, 2023
Spring-security, swagger, db auth , RestAPI

Rest API Features Spring-security Swagger-UI DB based Authentication Role Based Access Spring AOP Steps To Use go to /login screen go to swagger-ui.ht

Aniruddha Stark 1 Mar 12, 2022
A desktop java GUI application to encrypt your plain text

A desktop java GUI application to encrypt your plain text

Nikhil Narayanan 4 Sep 10, 2022
A Basic Java Application Vulnerable to the Log4Shell RCE

This is a basic, minimal, intentionally vulnerable Java web application including a version (2.14.1) of the log4j library affected by the infamous log4shell (CVE-2021-44228) vulnerability.

null 31 Nov 9, 2022
Easy to use cryptographic framework for data protection: secure messaging with forward secrecy and secure data storage. Has unified APIs across 14 platforms.

Themis provides strong, usable cryptography for busy people General purpose cryptographic library for storage and messaging for iOS (Swift, Obj-C), An

Cossack Labs 1.6k Dec 29, 2022
Hdiv CE | Application Self-Protection

New to Hdiv? Check this out Hdiv: Application Self-Protection Hdiv is a leading provider of open source software for real-time, self-protected applica

Hdiv 208 Nov 14, 2022
This application can recognize the sign language alphabets and help people who do not understand sign language to communicate with the speech and hearing impaired.

Sign Language Recognition App This application can recognize the sign language alphabets and help people who do not understand sign language to commun

Mihir Gandhi 12 Oct 7, 2021
Spring boot application to display number of corona cases

Corona-Cases-Counter Spring boot application to display number of corona cases This application consumes data from a CSV file which was used to docume

Hudson Obai 3 Aug 29, 2021
First Blood Donor Application

Find Blood Donor This is an android application which helps users to find blood donor's in their nearby locality. Why did you made this? My project "F

Kartik Soni 2 Oct 7, 2021