Index Changes

Difference between version and version     

Back to Systemic Qualities.Password Handling, or Systemic Qualities.Password Handling Info


At line 1 changed 2 lines.
!!!Requirements and Analysis
----
%%tabbedSection
%%tab-RequirementsAndAnalysis
At line 4 removed 1 line.
At line 37 added 2 lines.
%%
%%tab-Design
At line 39 removed 3 lines.
!!! Design
----
At line 70 changed 3 lines.
# PH1 – Passwords will not be allowed to be embedded in application artifacts. They will be exported using the environment variable design. This design will not be detailed in this document.
# PH2 – A schema will be provided that details the configuration of the component. This schema will be available to all tools to discern what fields need to be masked. (This strategy may change in the future and has not been completely flushed out.)
# PH3, PH4 – The JBI Framework will provide an implementation of KeyStoreUtil which will allow components to encrypt and decrypt strings. It is up to the component to properly use the utility on all fields that are designated as passwords.
# PH1 – Passwords will not be allowed to be embedded in application artifacts. They will be exported using the environment variable design. This design will not be detailed in this document.
# PH2 – A schema will be provided that details the configuration of the component. This schema will be available to all tools to discern what fields need to be masked. (This strategy may change in the future and has not been completely flushed out.)
# PH3, PH4 – The JBI Framework will provide an implementation of KeyStoreUtil which will allow components to encrypt and decrypt strings. It is up to the component to properly use the utility on all fields that are designated as passwords.
At line 84 added 1 line.
\\
At line 88 added 1 line.
\\
At line 92 added 1 line.
\\
At line 96 added 1 line.
\\
At line 100 added 1 line.
\\
At line 104 added 1 line.
\\
At line 109 changed 10 lines.
! Interfaces
Exported Interfaces
Interface Name
Proposed Stability Classification
Specified
Former Stability Classification
KeyStoreUtil
Unstable
[Provide a reference to the actual interface]
None
! Exported Interfaces
||Interface Name || Proposed Stability Classification || Specified || Former Stability Classification
|KeyStoreUtil | Unstable | [Provide a reference to the actual interface] | None
At line 120 changed 6 lines.
Imported Interfaces
Interface Name
Proposed Stability Classification
Specified
Former Stability Classification
PasswordAdapter
! Imported Interfaces
||Interface Name || Proposed Stability Classification || Specified || Former Stability Classification
|PasswordAdapter| Unstable | [Provide a reference to the actual interface] | None
|IdentityManager| Unstable | [Provide a reference to the actual interface] | None
At line 127 changed 1 line.
[Provide a reference to the actual interface]
!Implementation Considerations
* Persistence of Keys
** Implementations of KeyStoreUtil should obfuscate keys when storing them in a KeyStore
** Persistence is assumed to occur immediately and atomically with each of the Create, Update, and Delete operations for keys on KeyStoreUtil
* Clustering synchronization
** (Need input from Keith Babo)
** Client considerations when using KeyStoreUtil
** The KeyStoreUtil interface is very simple and basic. However certain considerations need to be addressed in obtaining this interface and using it. These questions should be considered in providing a client-side library:
###If the framework does not provide an implementation of this class, what should the client do? Should the client fail, use another utility, or simply expose the passwords in clear text?
### Getting the KeyStoreUtil interface from the framework requires casting to an interface specific to the JBI Framework. This limits portability of our components. Can we fix this in some way?
At line 129 changed 16 lines.
IdentityManager
Implementation Considerations
Persistence of Keys
Implementations of KeyStoreUtil should obfuscate keys when storing them in a KeyStore
Persistence is assumed to occur immediately and atomically with each of the Create, Update, and Delete operations for keys on KeyStoreUtil
Clustering synchronization
(Need input from Keith Babo)
Client considerations when using KeyStoreUtil
The KeyStoreUtil interface is very simple and basic. However certain considerations need to be addressed in obtaining this interface and using it. These questions should be considered in providing a client-side library:
1.If the framework does not provide an implementation of this class, what should the client do? Should the client fail, use another utility, or simply expose the passwords in clear text?
2.Getting the KeyStoreUtil interface from the framework requires casting to an interface specific to the JBI Framework. This limits portability of our components. Can we fix this in some way?
Limitations of interfaces
! Limitations of interfaces
At line 146 removed 3 lines.
Example usage of interfaces
The Password Handling classes and interfaces are fairly simplistic. The following examples will show how to use them.
Obtaining a KeyStoreUtil
At line 136 added 4 lines.
! Example usage of interfaces
The Password Handling classes and interfaces are fairly simplistic. The following examples will show how to use them.
* Obtaining a KeyStoreUtil
{{{
At line 146 added 1 line.
}}}
At line 157 changed 1 line.
Environment Variables
! Environment Variables
At line 150 added 1 line.
\\
At line 160 changed 1 line.
{{{
At line 166 changed 3 lines.
for (Iterator iter = mEnvVarMap.keySet().iterator(); iter.hasNext(); ) {
String key = (String) iter.next();
String[] metadata = (String[]) mEnvVarMap.get(key);
for (Iterator iter = mEnvVarMap.entrySet().iterator(); iter.hasNext(); ) {
Map.Entry entry = (Map.Entry) iter.next();
String key = (String) entry.getKey();
String[] metadata = (String[]) entry.getValue();
At line 208 added 1 line.
}}}
At line 216 changed 1 line.
Mbean Classes
! Mbean Classes
At line 218 changed 1 line.
{{{
At line 246 added 1 line.
}}}
At line 248 added 4 lines.
! User Interface
There are multiple clients that have the ability to view and set passwords. These clients include, but are not limited to, the JBI Manager, Enterprise Manager, the WSDL Editor, and the the CLI. The main underlying principle driving the client interface is that component code should __not rely on the client to properly mask passwords__. To that end, we have established the following criteria:
# __Make password fields write-only.__ Do not allow the clients to "get" the password. This will basically allow no client to inadvertently get the password and expose it to the outside world. For the JBI Manager and Enterprise Manager, we can certainly designate the MBean fields as write-only by providing just a setter method. For the WSDL editor, this is much more difficult since the passwords are stored in a WSDL file that is viewable by all. For CLI, the same problem exists since passwords are often stored in Properties files which are viewable by all.
# __Provide a "proper" password editor.__ The only time passwords can be exposed, then, is when the user is setting them. To ensure the integrity of the password, we want to provide the typical password editor that will allow the user to enter the password twice and have the option of having it masked when typing it in.
At line 254 changed 6 lines.
User Interface
There are multiple clients that have the ability to view and set passwords. These clients include, but are not limited to, the JBI Manager, Enterprise Manager, the WSDL Editor, and the the CLI. The main underlying principle driving the client interface is that component code should not rely on the client to properly mask passwords. To that end, we have established the following criteria:
1.Make password fields write-only.
Do not allow the clients to "get" the password. This will basically allow no client to inadvertently get the password and expose it to the outside world. For the JBI Manager and Enterprise Manager, we can certainly designate the MBean fields as write-only by providing just a setter method. For the WSDL editor, this is much more difficult since the passwords are stored in a WSDL file that is viewable by all. For CLI, the same problem exists since passwords are often stored in Properties files which are viewable by all.
2.Provide a "proper" password editor.
The only time passwords can be exposed, then, is when the user is setting them. To ensure the integrity of the password, we want to provide the typical password editor that will allow the user to enter the password twice and have the option of having it masked when typing it in.
%%
%%

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-6) was last changed on 27-Jan-10 02:38 AM, -0800 by newacct