[alf-req] ALF Requirements Meeting Minutes 9/7/2005

["Kelly Shaw" <kshaw@xxxxxxxxxx>]

ALF Requirements Meeting Minutes

9/7/2005

 

Security Roles in ALF

 

Discussion: Today's meeting concentrated on resolving the 'roles issue' within ALF. The central question is 'What roles do roles play within ALF.' We had two competing opinions about this issue, summarized below.

• Roles are necessary in ALF to enable service flows to execute with confidence. Without some central role administration capability, the tools themselves would be responsible for maintaining security and permissions, causing an administrative nightmare. Also, without these roles to manage permissions and authorizations across all tools, we have a free-for-all where every service call has the potential to cause a cascading and complex necessity to invoke compensating services. Rather than increasing the complexity of ALF, including both role and user administration will reduce its complexity.
• Roles have no place in ALF, at least for now. First, since we have already decided that ALF will not require user administration, there will be no users with which to associate ALF role permissions. Second, tool vendors will be unlikely to delegate security to an integration platform such as ALF, so administering ALF roles would require role administration within the tools as well, which is unworkable. Third, requiring web services to authenticate or retrieve role information from ALF would require vendors to write services specifically for consumption by ALF, setting the ALF compliance bar too high.

We debated these two viewpoints, and came to the following conclusions.

1. we can't force vendors to adopt LDAP for role definition. That would set the ALF entry bar too high.
2. we can't force vendors to respect ALF roles. That would set the ALF entry bar too high.
3. We need to allow vendors to respect ALF security roles, if these roles exist. Therefore, there must be a hook into ALF for defining security roles. This means an SPI.
4. We need to architect ALF in such a way that security roles can be added to the core product in the future.

The team agreed to monitor the open source and standards bodies such as Eclipse, Apache and Oasis to see if some security or trust system emerges that should be adopted by ALF. Meanwhile, we will ask potential ALF customers how they see the role of roles in ALF.

 

Action Items:

• Committee to continue discussions on roles, and continue to monitor Higgins (WS-TRUST) and other security projects to see if one of them should be adopted as the ALF authorization standard.
• Committee members to discuss role requirements with potential ALF adopters.
• Committee to continue discussions within the newsgroup.
• Committee members also on the Architecture team to convey the need for a role-hole to be designed into ALF.

 

Decision:

ALF can't dictate a role administration structure at this time. However, ALF should allow implementation sites to incorporate role administration, perhaps through a SPI. Additionally, ALF should be architected and designed to allow role administration to be added in the future.

 

UDDI - Service Directory within ALF

 

Discussion: The committee needs to address the following questions.

• Does ALF need a Service Directory?
• If so, what are the use cases for Service Directory use within ALF? What are the requirements?
• Given the requirements, is the UDDI standard appropriate?
• Are there other Service Directory standards at which we should be looking?
• Should we allow vendors to publish a directory of ALF-enabled services on the ALF site? Will we lose credibility as an open source project if we allow vendors to 'advertise' their services?

At this time nobody could think of a competitive alternative to UDDI. UDDI has many features that would make it interesting within the AL framework.

 

Action Item: Committee members will get smart about UDDI and any other Service Directory standards available. This discussion will continue next week.

 

Decision: None.

Next Meeting

The next requirements meeting will be from 10:00 - 11:00 Pacific on Wednesday, 14 September. Shaw will send the meeting announcement to alf-events and alf-req. Shaw will send an agenda to the mail group alf-req.

Kelly Shaw

Sr. Product Marketing Manager

Serena Software

719-457-8811

**********************************************************************

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.