Copyright © Cloud Software Group, Inc. All Rights Reserved

Security Token Files

When a security domain requestor uses a security token file to connect to a metaspace, ActiveSpaces uses the contents of the security token to:

1.	Restrict the metaspaces to which a security domain requestor can connect.

2.	Ensure the identity of the security domain controller.

3.	Determine the level of transport security the security domain requestor should use for TCP communication.

The same token file can be shared by different security domain requestors. If you use the same token file for different requesters, consider the following:

•	If the token does not have an ID, the tokens used by different requestors on the same metaspace will probably look the same.

•	However, if the tokens do have an ID, you should avoid sharing it as their certificates will be the same.

Creating a Security Token File

You generate a security token file from a security policy file using the Admin CLI.and an existing security policy file. The following example shows the Admin CLI common for generating a security token file:

as-admin> create security_token
domain_name "mydomain"
policy_file "mypolicy.txt"
token_file "mytoken.txt"

This command generates a security token file that contains the following information from the specified security domain in the security policy file:

•	The Metaspace Access List

•	The Transport Security setting

•	The public certificate of the security domain

See Chapter 2, “Administering ActiveSpaces with the Admin CLI “in the TIBCO ActiveSpaces Administration document for information on the define | create security_token command.

Limiting Metaspace Access

Typically, you do not need to edit a security token file. The one case where you might want to edit a security token file is when a security domain is associated with more than one metaspace, but you want to make sure that a security token file can only be used to connect to a specific metaspace.

When a security domain is associated with more than one metaspace, the Metaspace Access List for the security domain contains multiple metaspace_access entries in the security policy file. When you generate a security token file from the security policy file, multiple metaspaces are listed in the security token file. To restrict the metaspaces that can be connected to using this security token file, remove the metaspace_access entries for connections that should not be allowed.

See Metaspace Access List for more information about the format of the Metaspace Access List in security policy files.

Validating a Security Token File

You validate security token files using the Admin CLI. After you have finished generating or editing a security token file, you should validate the file to make sure that the token file is valid before you try to actually use it. The following example shows the Admin CLI command to validate a security token file:

as-admin> validate token_file "mytoken.txt"

Security Token File Keys and Certificates

When you generate a security token file from a security policy file, the public certificate of the domain identity in the security policy file is copied to the security token file. When a security domain requestor attempts to connect to a metaspace using the security token file, the connection fails if the public certificate in the security token file does not match the security domain controller's identity certificate.

By default, security token files do not contain a private key and public certificate for establishing the identity of the security domain requestor. Thus, when a security domain requestor attempts to connect to a metaspace, a temporary private key and public certificate are dynamically created for the security domain requestor to establish secure connections with. This key and certificate are valid for the duration of its connection to the metaspace.

Optionally, when you generate a security token file you can specify creation of a private key and public certificate. The following example shows the Admin CLI command to generate a security token file with a private key and public certificate for establishing a security domain requestor's identity for secure transport connections:

as-admin> create security_token

domain_name “mydomain”

policy_file “mypolicy.txt”

create_identity

            token_file “mytoken.txt”

See Restricting Transport Access for information on how generating a private key and public certificate in the security token file can be used to restrict access in a security domain to only certain security domain requestors.

Metaspace Access List

Each domain defined in a security policy file contains a Metaspace Access List. The Metaspace Access List restricts the security behavior defined by the settings for its security domain to only those metaspaces specified in the list. A metaspace can only belong to one security domain.

Each item in the Metaspace Access List must follow the format:

metaspace_access=metaspace=<metaspace name>;discovery=<discovery URL>

where:

•	metaspace name is the name of the metaspace (no quotes)

•	discovery URL is the TCP discovery URL of the metaspace (no quotes)

For example, to add the metaspace 'examplems' with a discovery URL of 'tcp://192.168.0.10:50000' to the Metaspace Access List for the domain 'mydomain' in the security policy file mypolicy.txt:

1.	Open mypolicy.txt in a text editor.

2.	Find the Metaspace Access List for the security domain mydomain.

3.	Modify the following line in the Metaspace Access List:

metaspace_access=metaspace=mydomain-ms1;
discovery=tcp://127.0.0.1:50000

to read:

metaspace_access=metaspace=examplems;
discovery=tcp://192.168.0.10:50000

4.	Save mypolicy.txt.

5.	To add additional metaspaces to the metaspace access list add, another metaspace_access item after the first metaspace_access item. For example:

metaspace_access=metaspace=examplems;
discovery=tcp://192.168.0.10:50000

metaspace_access=metaspace=examplems2;
discovery=tcp://192.168.0.11:50001

When you generate a security token file from a security policy file, the Metaspace Access List for the specified security domain is copied from the security policy file into the security token file. A security domain requestor using the security token file is allowed to connect to any of the metaspaces in the Metaspace Access List. To further restrict which metaspaces can be connected to, you should edit the security token file and remove any undesired metaspaces from the Metaspace Access List.

Copyright © Cloud Software Group, Inc. All Rights Reserved