[alf-dev] ALF Requirements Meeting Minutes from 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.
  a.. 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.
  b.. 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:
  a.. 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.
  b.. Committee members to discuss role requirements with potential ALF
adopters.
  c.. Committee to continue discussions within the newsgroup.
  d.. 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.
  a.. Does ALF need a Service Directory?
  b.. If so, what are the use cases for Service Directory use within ALF?
What are the requirements?
  c.. Given the requirements, is the UDDI standard appropriate?
  d.. Are there other Service Directory standards at which we should be
looking?
  e.. 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