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)
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?
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
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,
-
In JEE managed mode, such as an EntityManager injected into a SessionBean, the EntityManager reference, represents a new persistence context for each transaction. This means objects read in one transaction become detached after the end of the transaction, and should no longer be used, or need to be merged into the next transaction. In managed mode, you never create or close an EntityManager.
Transactions
operations that are committed or rolled back as a single unit
JPA provides two mechanisms for transactions
JTA (Java Transaction API
EntityTransaction
all changes made to all persistent objects in the persistence context are part of the transaction.
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
The SHOW PROFILES and
SHOW PROFILE statements display
profiling information that indicates resource usage for
statements executed during the course of the current session.
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.