ࡱ > / 1 . 3 4 5 6 7 8 9 _ '` 3- bjbj .J 3% $ $ $ $ $ $ $ 8 D , 8 ; l 2 2 2 2 2 2 2 ~; ; ; ; ; ; ; $ k= h ? z ; $ 2 2 2 2 2 ; $ $ 2 2 ; 2 $ 2 $ 2 ~; 2 ~; 8 $ $ ; 2 &K 9 ~; ; 0 ; 9 \ M@ | M@ 0 ; ; M@ $ ; h 2 2 2 2 2 2 2 ; ;
2 2 2 ; 2 2 2 2 8 8 8 < d
8 8 8 < 8 8 8 $ $ $ $ $ $ HIVE Security Management
Principles
The Security Management primary consists of two parts:
HeuristicLab.Security.* implements a generally version of authentication and authorization where PermissionOwners (Users, Groups,) are mapped to several Permissions (defined by a plugin). Therefore, a database will be queried whenever a PermissionOwner attempts to log on or use a special service.
HeuristicLab.Hive.Server.Core implements the plug in-specific rule set which connects execution logic to user tasks.
To provide a common and system-wide authorization model, a security service is exposed within HeuristicLab.Security: SecurityManager Service allows users to add, modify and delete PermissionOwners, Permissions and so on. It does not infer any pre-defined roles or permissions.
The final realization of the permission concept has to be implemented by a plug-in which takes advantage of the security service:
EMBED Visio.Drawing.11
Defining Permissions
In HIVE, permissions are stored in a XML document called HivePermissionSet.xml. The XML instance can be validated through HivePermissionSet.xsd as scheme information. A typical permission entry looks like this one:
A477BEA9-9C05-477f-AD9E-F76C510DDB0B
Add any job.
HeuristicLab.Hive
It contains the permission name, its ID as Guid, a short description to identify the permission and the corresponding plug in where this permission will be used.
But there are some additional naming conventions for permission: As you can see, a permission name has to be unique and looks like a namespace. In fact, the used name is exactly the namespace where the permission is located. When adding a permission, you will also have to append another namespace target in HivePermissions class.
Adding a new permission
Once you added another permission in HivePermissionSet.xml, you should extend the HivePermissions class located in Hive.Server.Core.Authorization. Every generic term (e.g. Jobmanagement) is represented as class which contains more specific terms (e.g. Read) as enumeration type. At least an enumeration uses flags to set the last instance of a permission (e.g. Any). This instance is also known as Scope. So when you want to add the permission HivePermissions.SomeResource.SomeAction.SomeScope you will have to perform these steps:
Create a new static class SomeResource in HivePermissions.
Create a new enum SomeAction within this class.
Add an enumeration value SomeScope as flagged value within this enum.
This concept is used to securely access permissions at design time. You are now able to receive a permission by its name (and be glad to have Intellisense on your side).
Extracting Permissions
Permissions located in HivePermissionSet.xml must have been loaded and parsed before any operation using security control takes place. This task is processed by HivePermissions class which loads permissions and policies at startup. You can access those by called the Getters (GetPermissions() or GetPolicies()). So this class is the only resource for identifying permissions and policies and will be used by HivePermissionManager.
Defining Policies
A policy is used to define several permissions for a target action, like this one:
Again, a policy is identified by its name, in this case AccessJobs. This name will be used in logic when authorization is needed:
secMan.Authorize("AccessJobs", sessionID, Guid.Empty);
When access is denied, a FaultException will be raised and returned to caller. A permission can be ordered using the optional priority attribute. The name of a permission must be equal to the name specified in HivePermissionSet.xml. At least an optional context attribute sets the scope. Pre-defined scopes are:
AnyMeans, any resource can be modified.
ProjectOnlyDepends on the project id, if a user is allowed to perform a certain action.
OwnedOnlyIn that case, only access to owned resources is allowed.
Apply Policies
When everything is prepared in XML instances and previous named classes, at least the database needs to be updated (add permission and grant it to several owners). This task is currently performed using a test project (SecurityCoreTest).
Installing and Using certificates for HL HIVE application
In order to use secure connections between various HIVE Plug-Ins you have to install a certain certificate previously. The certificate has to be generated and published by the machine that runs HIVE server application and therefore provides the WCF services.
Generating a new server certificate for secure messaging purposes
Normally, the certificate has to be generated by a domain controller (e.g. Microsoft Certification Services) and gets additionally validated by a third-party validation provider like VeriSign. When using certificates in a testing environment, a self-generated certificate can be used. To do so, you have to follow these steps to create a certificate on your machine that is used as server:
Run the batch file GenerateServiceCertificate.cmd. It should be located in the same folder where this document is stored. When executing this file, you might get an error message (code: 0x5). This error occurs when you have insufficient rights on. In that case you must use some workaround described below. Otherwise proceed with step 2.
Start the management console by typing mmc certmgr.msc into the command shell.
Locate the generated certificate. The name of the certificate is HIVE-Server and normally placed in the Personal folder:
Double-Click on the certificate and click on the Details tab:
Scroll down until you see the Thumbprint field:
Mark the displayed thumb print and use CTRL+C to copy it into the clipboard or save it into a text file. Now you can close the management console.
Workaround for Restricted Access on LocalMachine Store:
If you cannot create a certificate in the local machine store (defined by the sr attribute) you have to choose the current user store. Therefore replace the option -sr LocalMachine with -sr CurrentUser and run the batch file again. This time the creation must be successful and the Succeeded. message should appear. Because the HIVE application normally looks in the local machine store for the correct certificate, you also have to change the settings in code which means you have to edit the WcfSettings file located in Hive.Client.Contracts . Set the StoreLocation attribute to StoreLocation.CurrentUser in the SetServiceCertificate() method and save the file.
Installing the server certificate on clients
When using a certificate for secure communication, you have to manually install a certificate on the client machine. When a validated server certificate is provided, those tasks can be performed automatically because the thumbprint wont change.
Perform following steps to install the previously generated certificate:
Open the batch file InstallClientCertificate.cmd with an editor.
Depending on the used operating system select the correct tool and mark out the one you wont use.
Replace the current hash code (thumbprint) with the one you have saved before. Otherwise locate the service certificate on the server and perform tasks 4-6 from the previous chapter again.
You should get a message displayed like HttpSetServiceConfiguration completed with 0. Otherwise you still have restricted rights to perform a http service configuration.
Current Progress
At this time everything is prepared to ensure secure transport of messages, but actually it is not activated.
What happened so far?
A server certificate was published on the Blade System. This will be used for clients to authenticate the server.
The bindings can be reconfigured to use certificates and secure channels by changing the pre-compiler var USE_MSG_BINDING definement. Notice: All connections will be secured by default! You find the connection settings (bindings) in HeuristicLab.Hive.Contracts.WcfSettings.cs .
There is a chance to automatically install the client certificate using the batch file mentioned above. This task has to be performed once for every client that needs access to services hosted by the common server (Blade System). Notice: Administrative rights are needed in order to install a certificate in the correct store.
What has to be done?
Because all connections will be secured when activating secure binding, transmission of huge data (like jobs) will reduce performance dramatically. Therefore it is advised to split up channels in secured and unsecured ones to ensure better overall performance.
Other Plug-ins will also use certain services, like Security Service and so, the binding configuration has to be identically for each Plug-In. Currently there is a problem matching the bindings with other projects, this should happen in a more general way. A possibility would be to take advantage of .NET 4.0 which supports service discovery and/or a centralized store/service host. These concepts should be determinated before implementing additional services.Appendix
HIVE Role Management
$ % U T
q
? ^ c d u ɽɽɽɱi 8h h B*CJ OJ QJ ^J aJ mH nH ph sH u h mH sH ju8M
h}| UVh}| j h}| Uh}| OJ QJ mH sH h OJ QJ mH sH h OJ QJ mH sH h N OJ QJ mH sH hh( OJ QJ mH sH hh( hh( OJ QJ mH sH h7X hh( h7X OJ QJ % \
C
j
z
{
h 7$ 8$ H$ gd gd gd37 gd gd N
&