HAI Use Case: Authentication mechanism compatibility with OC and Java DAP libraries: Difference between revisions

Latest revision as of 19:05, 9 November 2010

Point Of Contact: Nathan Potter

Description

Authentication mechanism compatibility

Goal

To ensure that whatever develops in the line of user authentication and access control for Hyrax is kept compatible with clients.

Summary

Efforts to implement changes to user authentication and access control activities for Hyrax can easily end up focusing on browser based activities because this is the manner of interacting with a DAP server that most humans experience. However the real power of the DAP server is that it machine crawlable and accessible and can be utilized by a collection of existing automation clients. It is important that we do nothing to break these clients. It may be that core changes that can break existing client need to be tied to newer versions of the DAP.

Actors

Existing DAP client software: OC library, Java-DAP
Hyrax
Developers

Preconditions

The desire to keep the overall data system working.

Triggers

Changes to authentication mechanisms for Hyrax

Basic Flow

Evaluate potential authentication mechanism changes on existing DAP client libraries. Mitigate changes by one or of:

rollback
update client
hide change from older clients through protocol version

Alternate Flow

Here we give any alternate flows that might occur. May include flows that involve error conditions. Or flows that fall outside of the basic flow.

Post Conditions

Here we give any conditions that will be true of the state of the system after the use case has been completed.

Activity Diagram

Here a diagram is given to show the flow of events that surrounds the use case.

Notes

There is always some piece of information that is required that has no other place to go. This is the place for that information.

Resources

In order to support the capabilities described in this Use Case, a set of resources must be available and/or configured. These resources include data and services, and the systems that offer them. This section will call out examples of these resources.

Resource	Owner	Description	Availability	Source System
name	Organization that owns/ manages resource	Short description of the resource	How often the resource is available	Name of system which provides resource

@@ Line 1: / Line 1: @@
-'''Point Of Contact:''' ''A Human''
+[[Category:HAI]]
+'''Point Of Contact:''' ''[[User:ndp | Nathan Potter]]''
 == Description ==
-<font size="-2" color="green">''Give a short descriptive name for the use case to serve as a unique identifier.''</font>
+Authentication mechanism compatibility
 == Goal ==
-<font size="-2" color="green">''The goal briefly describes what the user intends to achieve with this use case.''</font>
+To ensure that whatever develops in the line of user authentication and access control for Hyrax is kept compatible with clients.
 == Summary ==
-<font size="-2" color="green">''Give a summary of the use case to capture the essence of the use case (no longer than a page). It provides a quick overview and includes the goal and principal actor.''</font>
+Efforts to implement changes to user authentication and access control activities for Hyrax can easily end up focusing on browser based activities because this is the manner of interacting with a DAP server that most humans experience. However the real power of the DAP server is that it machine crawlable and accessible and can be utilized by a collection of existing automation clients. It is important that we do nothing to break these clients. It may be that core changes that can break existing client need to be tied to newer versions of the DAP.
 == Actors ==
-<font size="-2" color="green">''List actors, people or things outside the system that either acts on the system (primary actors) or is acted on by the system (secondary actors). Primary actors are ones that invoke the use case and benefit from the result. Identify sensors, models, portals and relevant data resources. Identify the primary actor and briefly describe role.''</font>
+* Existing DAP client software: OC library, Java-DAP
+* Hyrax
+* Developers
 == Preconditions ==
-<font size="-2" color="green">''Here we state any assumptions about the state of the system that must be met for the trigger (below) to initiate the use case. Any assumptions about other systems can also be stated here, for example, weather conditions. List all preconditions.''</font>
+The desire to keep the overall data system working.
 == Triggers ==
-<font size="-2" color="green">''Here we describe in detail the event or events that brings about the execution of this use case. Triggers can be external, temporal, or internal. They can be single events or when a set of conditions are met, List all triggers and relationships.''</font>
+Changes to authentication mechanisms for Hyrax
 == Basic Flow ==
-<font size="-2" color="green">''Often referred to as the primary scenario or course of events. In the basic flow we describe the flow that would be followed if the use case where to follow its main plot from start to end. Error states or alternate states that might be highlighted are not included here. This gives any browser of the document a quick view of how the system will work. Here the flow can be documented as a list, a conversation or as a story.(as much as required)''</font>
+Evaluate potential authentication mechanism changes on existing DAP client libraries.
+Mitigate changes by one or of:
+* rollback
+* update client
+* hide change from older clients through protocol version
 == Alternate Flow ==