Wrap CurrentDetails and EventContext with SecuritySystem

[jamoore]

The ThreadLocal CurrentDetails should be made package private and wrapped by a SecurityManager (name TBD) that will be the central logical unit for all security tests. The single, Spring-configured instance will be injected into other server objects which need to perform security logic. SecurityManager will coordinated with the ome.model.internal.Permissions class and Hibernate filters for providing read and possibly write security. Write security may be handled by the Hibernate validation system.

[jmoore]

Most likely needed for #156 (System-Types). A central component will need to "know" what the System-Types are. We shouldn't be spreading ISystem.class.isAssignableFrom( thing.getClass() ) calls all around the place.

[jmoore]

Plan :

• lower visibility on CurrentDetails
• gather all calls to user.getId().equals( 0L )
• inject SecurityManager where needed (ome/services/security.xml)
• inject EventContext only into SecurityManager (ome/services/security.xml)

will wait on #180 for working out the separation of responsibilites between SecurityManager and Permissions.

[jmoore]

Name switch. SecurityManager is in java.lang and that's a hassle. Floor is open for suggestions. Temporarily switching to SecuritySystem to keep moving.

[jmoore]

r768 implements a BasicSecuritySystem which does not use ITypes (#86) for defining SystemTypes (#156) but defines them programmatically:

 if ( object instanceof Experimenter ) ...

We will definitely want to revist BasicSecuritySystem to make it more configurable and which objects have the SecuritySystem injected. This can take place in other tickets. Simiarly for collecting all miscellaneous calls to user.getId().equals( 0L ) or new Experimenter( 0L, false ).

[jmoore]

r826 adds lots of mock testing for the BasicSecuritySystem so this is even more closed.

[jmoore]

r827 extends SecuritySystem/CurrentDetails and others with the wished group leader ("PI") logic. No ticket available.