One of the key components of the Sail System will be users. The Sail User System or SUS will be responsible for everything from user creation to user security. In order to create the SUS, a good plan of action would be to:
1. Develop a set of features needed by the SUS.
2. Develop requirements for each feature.
Feature Set:
User Creation
1. Have a facility to create users with different Roles and groups.
- Role List
- Example Group List
- TELS authoring group
- xyz school learner group
- xyz school research group
etc...
Possible implementation:
JXTA Group/Membership Service
The membership service provides access to a group-specific version of the Peer Membership Protocol. It is used as a gatekeeper to membership in the group.
- Peers wanting to join the group must fulfill the requirements of this service. The model is that of a membership application form where a document is submitted to the peer to be filled in and submitted for approval. If the peer is approved, the peer is considered a member of the group and is issued a credential that is used as proof of membership during communications.
- The membership service can extend the model from an application to external validation (such as a server that validates the user's initial credential) or by querying other peers or a manager peer for final approval (voting).
User Security
1. The ability to encrypt user data(user passwords, transactions, etc...)
2. The ability to authenicate users
3. The ability to grant authorization to users
Possible implementation:
JXTA Access Service
The access service is part of the membership service and is used to ensure that the peers are actually valid members of the group. This service uses the credential created when the peer joined the group. A peer receiving a request provides the requesting peer's credentials and information about the request being made to the access service, and the service determines if the context and credentials are correct; if so, access is permitted.
JXTA Peer Authentication Service
The authentication service uses credentials created by the membership protocol to verify that that messages are from a valid member of the group. The concept is that the application examines a credential for certain operations as needed to ensure that communications are with valid peers.
- Authentication uses the credential as a standalone packet of information that is either self-authenticating or can be verified with other information the current peer obtained from another source.
User Monitoring
1. Have the ability to track user actions.
question: what user actions require monitoring?
Possible implementation:
JXTA Monitoring Service
The monitoring service is used to allow a peer to monitor other group members of the peer group. The specification of what is monitored is left to the implementer. Monitoring can be used to collect data on peers to ensure they are following the group's rules for behavior or just to gather simple statistics.
The reasons for having a monitoring service are many. The following are a few:
- Keep a log of peer activities (downloads, contributions, and so on) that are sent to other peers. This relates to the next item.
- You could manage a peer's ability to use the group. This is similar to Gnutella that prevents a peer from downloading unless they also share a minimum of their content. This can be expanded to include other information, such as up-time and other statistics that trigger certain rights. The opposite is that other peers receive these statistics before they interact with the peer, so that they can decide if they want to interact with the peer. This can be automated or just presented to the wizard behind the curtain.
- Management of the user access is also important. In the specification, there is no mention of a revocation of a group membership. There is the idea of expiration and renewal. The problem is that you may not want to wait for expiration and want to remove a user early. This relates back to using a credential, which is a part of the specification and can be used to notice when a user is no longer valid.
- Managing issues like those that cause problems in JXTA, including abuse of resources, falsification of identity, hacking/hijacking of the group for other purposes, and denial of service attacks against the group or some of its peers.