Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:COSMOS Design 209337"
Line 5: | Line 5: | ||
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 | 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 | ||
+ | |||
+ | |||
+ | --[[User:Martin.simmonds.ca.com|Marty]] 06:41, 17 January 2008 (EST) | ||
+ | * Authentication | ||
+ | # What authentication methods do we support? LDAP (OpenLdap), Basic Authentication (Authenticate against Tomcat users) ? | ||
+ | # Does Authentication traverse different Tomcat servers? | ||
+ | # Does Authentication traverse different OSGI servers? | ||
+ | # Does Authentication traverse Tomcat and OSGI? | ||
+ | # If Authentication is used in the COSMOS framework, what does an adopter have to do? | ||
+ | ## When they want to use it. | ||
+ | ## When they want to add their data source so that others can use it. | ||
+ | # If a user is not authenticated, what happens? | ||
+ | # If a user is authenticated what happens?, does that authentication result get stored in a token of some sort? | ||
+ | # Do authenticated users get timed out ? | ||
+ | # If a specific type of authentication is used, does this mean that we have to use that method throughout, or can we mix? | ||
+ | # How do we administer the authentication? | ||
+ | ## Cosmos should do this and integrate with the admin clients that are available for the method in question? | ||
+ | ## Cosmos should integrate with the admin apis if available (eg. [http://www.openldap.org/software/ OpenLdap] has a Java API)? | ||
+ | # For SSO we could use JOSSO as our test example [http://www.josso.org/confluence/display/JOSSO1/Architecture+Overview.html JOSSO] | ||
+ | * Authorization | ||
+ | # What are the roles ? | ||
+ | ## Admin | ||
+ | ## Anonymous | ||
+ | ## Application User | ||
+ | ## Others? | ||
+ | # Will LDAP be a mechanism for defining the users, their roles, their access? | ||
+ | # If LDAP is not used, | ||
+ | ## How will roles be defined? | ||
+ | ## Where will that data be stored? | ||
+ | ## How will it be administered? | ||
+ | * Encryption | ||
+ | # What Encryption methods do we use? | ||
+ | ## AES | ||
+ | ## Blowfish | ||
+ | ## RC2 | ||
+ | ## ARC4 | ||
+ | ## 3DES | ||
+ | ## Any others ? | ||
+ | # Can the Encryption method be chosen? If so how is that administered? | ||
+ | # Does a client have to choose the encryption, or is it dictated by how the Framework sets it up? | ||
+ | # Perhaps we should have only 1 method? | ||
+ | * Artifacts to be secured | ||
+ | # The Management Domain, Data Broker and Visualization are part of COSMOS, so this should pose few problems to secure them. | ||
+ | # Data Managers and MDRs are slightly different | ||
+ | ## Data Managers and MDRs can be directly accessed from a client, that has not necessarily passed the Domain and Broker Security. | ||
+ | ## 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). | ||
+ | # Queries and Result Sets | ||
+ | ## Are we assuming that the results are stored somewhere before they are retrieved? | ||
+ | ## Either the client has made a request and is waiting for a result set, or | ||
+ | ## The client has made the request, and waiting for notification that the resultset is available for viewing. | ||
+ | * Error Handling, Testing, Debuggng | ||
+ | # What happens when something goes wrong? | ||
+ | ## Where are things logged? | ||
+ | ## How do we test this? | ||
+ | ## How do we debug it? | ||
+ | * Security Providers | ||
+ | # How will we establish this list? | ||
+ | # How will we test them? | ||
+ | # The hooks need to be well defined | ||
+ | * WS-Security | ||
+ | # How do we ensure full support? | ||
+ | ## Investigate WS-Security implementations for existing Open Source Apps | ||
+ | ## Define a list of things to check | ||
+ | ## Dev/QA to check the list is fulfilled? |
Revision as of 07:41, 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
- What authentication methods do we support? LDAP (OpenLdap), Basic Authentication (Authenticate against Tomcat users) ?
- Does Authentication traverse different Tomcat servers?
- Does Authentication traverse different OSGI servers?
- Does Authentication traverse Tomcat and OSGI?
- If Authentication is used in the COSMOS framework, what does an adopter have to do?
- When they want to use it.
- When they want to add their data source so that others can use it.
- If a user is not authenticated, what happens?
- If a user is authenticated what happens?, does that authentication result get stored in a token of some sort?
- Do authenticated users get timed out ?
- If a specific type of authentication is used, does this mean that we have to use that method throughout, or can we mix?
- How do we administer the authentication?
- Cosmos should do this and integrate with the admin clients that are available for the method in question?
- Cosmos should integrate with the admin apis if available (eg. OpenLdap has a Java API)?
- For SSO we could use JOSSO as our test example JOSSO
- Authorization
- What are the roles ?
- Admin
- Anonymous
- Application User
- Others?
- Will LDAP be a mechanism for defining the users, their roles, their access?
- If LDAP is not used,
- How will roles be defined?
- Where will that data be stored?
- How will it be administered?
- Encryption
- What Encryption methods do we use?
- AES
- Blowfish
- RC2
- ARC4
- 3DES
- Any others ?
- Can the Encryption method be chosen? If so how is that administered?
- Does a client have to choose the encryption, or is it dictated by how the Framework sets it up?
- Perhaps we should have only 1 method?
- Artifacts to be secured
- The Management Domain, Data Broker and Visualization are part of COSMOS, so this should pose few problems to secure them.
- Data Managers and MDRs are slightly different
- Data Managers and MDRs can be directly accessed from a client, that has not necessarily passed the Domain and Broker Security.
- 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).
- Queries and Result Sets
- Are we assuming that the results are stored somewhere before they are retrieved?
- Either the client has made a request and is waiting for a result set, or
- The client has made the request, and waiting for notification that the resultset is available for viewing.
- Error Handling, Testing, Debuggng
- What happens when something goes wrong?
- Where are things logged?
- How do we test this?
- How do we debug it?
- Security Providers
- How will we establish this list?
- How will we test them?
- The hooks need to be well defined
- WS-Security
- How do we ensure full support?
- Investigate WS-Security implementations for existing Open Source Apps
- Define a list of things to check
- Dev/QA to check the list is fulfilled?