[alf-dev] Minutes from the Requirements Committee meeting on 8/25/2005 -

["Kelly Shaw" <kshaw@xxxxxxxxxx>]

Dear All,

 

I forgot to remove my logo from the email, so the contents of this message didn't get sent. Sorry, and here it is again.

 

Regards,

 

shaw

 

Dear All,

 

At today's meeting we discussed three main topics: the POC use case, raising events from service flows and SSON.

 

The use case was approved, with the request to break apart the Get/Build/Deploy steps in the service flow. Shaw will make the changes and post a new use case document reflecting these changes.

 

The committee discussed single sign-on (SSON) in detail because Cognizant needs the requirements in order to get to work developing the SSON infrastructure for ALF.

 

We considered two approaches to SSON within ALF. The first approach requires ALF to maintain a runtime (and perhaps eventually a persisted) credential store so service flows can get identity information as stored in ALF. (See the agenda for the 8/25/05 requirements meeting for a more detailed discussion.) The second approach merely required ALF to provide a service that encrypts identity information and a service that decrypts identity information.

 

After much discussion, the committee agreed that the only reason for ALF to maintain a credentials cache was if she wanted to support some form of user mapping between tools. We all agreed that user mapping should not be an ALF job, so opted for the encrypt/decrypt solution. As a best practice, we believe all ALF-enabled tools should support authentication through a central identity management tool such as LDAP. However, we agreed that ALF will not require such a tool. Instead, ALF will define a Service Provider Interface (SPI) that will allow ALF sites to implement user mapping if necessary.

 

In a nutshell, ALF will not maintain a credentials store. Instead, ALF will provide two web services to be used by tools and web service providers:

• Generate a credential token from a userid/role. We may want to include additional information such as tool context for reasons we can discuss later.
• Decrypt a set of credentials into userid/role. This decode operation may also decode context information for reasons we can discuss later.

This means ALF assumes user id information is consistent across all tools that play in an ALF instance. In general, this will mean that the tools will need to support LDAP or some other identity management tool, however ALF does not mandate any such tool. Administrators could, although it would be admittedly tedious, simply manually verify that all userids are consistent across all tools.

For ALF sites that do not want a common identity manager, and do not want to rely on tool administrator compliance with a same-id policy, ALF offers two alternatives.

• Tool vendors providing web services can define user id mapping as part of the web service, using a configuration and conversion method that is completely outside of ALF. For example, if user Joe in toolA maps to Sam in toolB, then if toolB's web service receives credentials from Joe in toolA, ToolB would convert the user to Sam. This user mapping is completely outside of ALF and is not supported by ALF, but is an avenue that ALF sites can use to work around the identity server requirement. In this case, the context information would probably be needed for the conversion in addition to the credential.
• ALF sites can use a Service Provider Interface (SPI) to convert Joe in toolA to Sam in toolB. The interface will have default no-op behavior in ALF. So, when the ALF Event Broker starts a service flow and sends in credentials and context information to the service flow, it first makes a call into the SPI to convert the credentials. By default ALF will return the same set of credentials it received, but the behavior can be overridden to provide cross-tool user mapping at ALF sites.

In either case, ALF is not responsible in any way for userid conversion. ALF merely provides web services to encrypt and decrypt credentials.

 

In addition to SSON, we discussed how to maintain an event audit trail for service flows that are 'chained.' For example, if one service flow generates an event that causes another service flow to execute, we thought it would be nice if there was an audit trail that pointed from the subsequent service to the prior service. To accomplish this we agreed that when an event is raised by a service, it must include the Event ID that triggered said event. This tells the service flow that it is not working with a 'primary' event so can't use the event ID to get information in a callback to a tool. We also theorize there may be cases where the service flow wants to act differently when it is being called as a result of a 'primary' event rather than a chained event. If anyone can think of a use case that supports this theory, please post it.

 

For example, assume service A starts as a result of event A1. During the Execution of A, A raises an event with ID A2. Now say that as a result of A2, service B starts. Service B will have an event ID of A2, but the parameters to Service B will also include a back reference to event A1.

 

Derived requirement: ALF must provide a web service, callable from a service flow, that raises and event. The event can forward the context and identity information from the triggering event, or can generate a new credentials token and set of reference information. The event must forward the Event ID reference as input to the service flow, and the event must also have a unique ID as generated by ALF.

 

Other topics.

 

We agreed to move the meetings to Wednesday rather than Thursday to give everyone a chance to consider the issues before the architecture meetings.

 

The next meeting will be from 10:00 - 11:00 Pacific on Wednesday, 31 August. See the ALF website for the updated documents and the agenda. I will also send the documents and agenda to the mail group.

 

Regards,

 

Kelly Shaw (I prefer to be called 'shaw' rather than 'kelly,' BTW.)

 

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

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.