Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Spaces/Authorization Support"

 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 
Spaces has a convenience implementation of authorization support that space providers can use if there are no special needs.
 
Spaces has a convenience implementation of authorization support that space providers can use if there are no special needs.
  
The implementation is found in the project "org.eclipse.spaces.core", and there is a test in "org.eclipse.spaces.test" (class "SpaceAuthroizationTest").
+
The implementation is found in the project "org.eclipse.spaces.core", and there is a test in "org.eclipse.spaces.test" (class "SpaceAuthorizationTest").
  
 
=Storing Authorization Information=
 
=Storing Authorization Information=
Line 79: Line 79:
  
 
The levels above space are useful when a user has one login/password for a larger group of spaces.
 
The levels above space are useful when a user has one login/password for a larger group of spaces.
 +
=Credentials=
 +
The implementation contains support for BasicCredentials (login/password), but can be extended. If you want to add a new type of credential, extend the class from "org.eclipse.spaces.core.Credentials".
 +
=Support for temporary Authorization=
 +
The SpaceAuthroization class supports temporary authorizations (they are lost when the java runtime exits). The temporary authorization information has higher precedence when getting information. (This means that there could be information in the keyring for a space, and temporary information for the space's source repo - when looking up the source repo information, the temporary information is returned.
 +
 +
To add temporary information, simply use the "SpaceAuthorization.add(...)" with a signature that takes a boolean to control persistency.
 +
 +
=Example - headless use=
 +
When using spaces headlessly, there are two options:
 +
* Create a target platform that has credentials stored in the keyring and use this target platform when running.
 +
* Pass credentials on the command line or read them from some file (up to how the headless commands work) and then either:
 +
** store them in the keyring if this is wanted by the user
 +
** store them in memory only (as shown above) - if the user prefers to pass credentials for every invocation

Latest revision as of 12:17, 20 January 2008

Spaces has a convenience implementation of authorization support that space providers can use if there are no special needs.

The implementation is found in the project "org.eclipse.spaces.core", and there is a test in "org.eclipse.spaces.test" (class "SpaceAuthorizationTest").

Storing Authorization Information

Here is an example of how to store authorization information for a space.

// A space URI
URI address = URI.create("spaces:local://user@localhost/MySpace1");

// Lookup the space
ISpace space = Spaces.getSpace(address);

// Create a space resource for the entire space
SpaceResource r = new SpaceResource(space);

// Add the authorization information
SpaceAuthorization.add(r,  new BasicCredentials("fred", "secret"));

This adds information that user "fred" with password "secret" is authorization information for anything in the space (and below).

Getting Authorization Information

Here is an example how to obtain the authorization information:

// A space URI
URI address = URI.create("spaces:local://user@localhost/MySpace1");

// Lookup the space
ISpace space = Spaces.getSpace(address);

// Create a space resource for the entire space
SpaceResource r = new SpaceResource(space);
BasicCredentials c = SpaceAuthorization.get(r, BasicCredentials.class);

String login = c.getLogin();
Stirng password = c.getPassword();

The SpaceResource

The SpaceResource specifies the root of a resource tree. Here is the hierarchy

Area Authorization for Example
provider provider, server, user, space, and all three areas flat, structured, and source new SpaceResource(space, SpaceResource.Type.PROVIDER)
server server, user, space, and all three areas flat, structured, and source new SpaceResource(space, SpaceResource.Type.SERVER)
user user, space, and all three areas flat, structured, and source new SpaceResource(space, SpaceResource.Type.USER)
space space, and all three areas flat, structured, and source new SpaceResource(space)
which is shorthand for:
new SpaceResource(space, SpaceResource.Type.SPACE)
flat the flat area of a space new SpaceResource(space, SpaceResource.Type.FLAT)
structure the structured area of a space new SpaceResource(space, SpaceResource.Type.STRUCTURE)
source the source area of a space new SpaceResource(space, SpaceResource.Type.SOURCE)

When a request is made to get authroization information for a space resource, the information added for the exact match, or the closest enclosing area's information is returned.

This makes it possible to just add authroization information for the space, and still request information for flat, structure, and source individually. If no specific information has been defined for these areas, the information stored for the space will be returned.

The levels above space are useful when a user has one login/password for a larger group of spaces.

Credentials

The implementation contains support for BasicCredentials (login/password), but can be extended. If you want to add a new type of credential, extend the class from "org.eclipse.spaces.core.Credentials".

Support for temporary Authorization

The SpaceAuthroization class supports temporary authorizations (they are lost when the java runtime exits). The temporary authorization information has higher precedence when getting information. (This means that there could be information in the keyring for a space, and temporary information for the space's source repo - when looking up the source repo information, the temporary information is returned.

To add temporary information, simply use the "SpaceAuthorization.add(...)" with a signature that takes a boolean to control persistency.

Example - headless use

When using spaces headlessly, there are two options:

  • Create a target platform that has credentials stored in the keyring and use this target platform when running.
  • Pass credentials on the command line or read them from some file (up to how the headless commands work) and then either:
    • store them in the keyring if this is wanted by the user
    • store them in memory only (as shown above) - if the user prefers to pass credentials for every invocation

Back to the top