Difference between revisions of "Talk:COSMOS Design 209337"

Revision as of 22:54, 17 January 2008

Jimmy, are there documented standards for security that can be referenced and linked to here ? Does WS-Security cover all the security topics that we want to address with this ER ? Paul

Paul, I added the "References" section. - Jimmy

Jimmy, I assume MD will have to establish some sort of session or pass back some token so that a client doesn’t just bypass the MD using the EPR of the broker directly. - Jack

--Marty 06:41, 17 January 2008 (EST)

• Authentication

1. What authentication methods do we support? LDAP (OpenLdap), Basic Authentication (Authenticate against Tomcat users) ?
2. Does Authentication traverse different Tomcat servers?
3. Does Authentication traverse different OSGI servers?
4. Does Authentication traverse Tomcat and OSGI?
5. If Authentication is used in the COSMOS framework, what does an adopter have to do?
   1. When they want to use it.
   2. When they want to add their data source so that others can use it.
6. If a user is not authenticated, what happens?
7. If a user is authenticated what happens?, does that authentication result get stored in a token of some sort?
8. Do authenticated users get timed out ?
9. If a specific type of authentication is used, does this mean that we have to use that method throughout, or can we mix?
10. How do we administer the authentication?
    1. Cosmos should do this and integrate with the admin clients that are available for the method in question?
    2. Cosmos should integrate with the admin apis if available (eg. OpenLdap has a Java API)?
11. For SSO we could use JOSSO as our test example JOSSO

• Authorization

1. What are the roles ?
   1. Admin
   2. Anonymous
   3. Application User
   4. Others?
2. Will LDAP be a mechanism for defining the users, their roles, their access?
3. If LDAP is not used,
   1. How will roles be defined?
   2. Where will that data be stored?
   3. How will it be administered?

• Encryption

1. What Encryption methods do we use?
   1. AES
   2. Blowfish
   3. RC2
   4. ARC4
   5. 3DES
   6. Any others ?
2. Can the Encryption method be chosen? If so how is that administered?
3. Does a client have to choose the encryption, or is it dictated by how the Framework sets it up?
4. Perhaps we should have only 1 method?

• Artifacts to be secured

1. The Management Domain, Data Broker and Visualization are part of COSMOS, so this should pose few problems to secure them.
2. Data Managers and MDRs are slightly different
   1. Data Managers and MDRs can be directly accessed from a client, that has not necessarily passed the Domain and Broker Security.
   2. Data Managers and MDRs may require a userid and password to access (for example) an Oracle database, so that information has to come from somewhere. Where will that be stored? I doubt if the user should be challenged for a userid and password, as that may become unusable (could be solved via SSO).
3. Queries and Result Sets
   1. Are we assuming that the results are stored somewhere before they are retrieved?
   2. Either the client has made a request and is waiting for a result set, or
   3. The client has made the request, and waiting for notification that the resultset is available for viewing.

• Error Handling, Testing, Debuggng

1. What happens when something goes wrong?
   1. Where are things logged?
   2. How do we test this?
   3. How do we debug it?

• Security Providers

1. How will we establish this list?
2. How will we test them?
3. The hooks need to be well defined

• WS-Security

1. How do we ensure full support?
   1. Investigate WS-Security implementations for existing Open Source Apps
   2. Define a list of things to check
   3. Dev/QA to check the list is fulfilled?

John.devine.ca.com 21:54, 17 January 2008 (EST)

Martin, The ER states that we'd like to support all the roles defined for the COSMOS User cases, but at present Jimmy thinks that it would be sufficient to have the "hook" in for roles, and only implement authentication in i9, and if authorization is to be considered at all, we'd limit ourselves to a privileged/not privileged two state hierarchy with administrative operations limited to the privileged users.

You've raised sufficient questions that we really need to schedule an architecture meeting whose sole purpose would be to nailing these specifics down.