[alf-dev] Re: Single Sign On and service flow needing multiple different

["Tim Buss" <tbuss@xxxxxxxxxx>]

Hi Daniel,

Yes that could be the case but SSO is not really the issue. It depends where
you are starting from and what you want to happen.

The original premise of ALF was that many tools provide their own
authentication and authorization and a major inhibitor to combining them
into a application was multiple logins.  This allows a user to use one login
but be mapped to the various authorizations in the various tools.  "Allows"
is the operative word here.  It is quite possible to combine actions in a
Service Flow such a way that the user will not be able to execute it because
one of more of the tools will raise an authorization exception.  In some
cases this is what you intend.  Often it is not.

To address this, authorization must be normalized across the tools in some
way. For example

1. Actually do it - This may be tedious to achieve.  You have to understand
how the authorizations combine.

2. Use Roles to make that easier - Roles reduce the complexity of
combinations by categorizing then into easy to understand buckets.  However,
Roles require that each tool has the same understanding of Role.  Possible
but not likely in the near term.

3. Delegate to a "configured" ALF user that does have access. - This the
easiest but security is reduced.  This method requires the tools to trust
ALFs assertion that the originating user is authentic.  Thus ALF should
authenticate the originating user before calling a tool using the ALF user,
really before calling a  service flow.  ALF should probably also provide an
authorization model around Service Flow dispatch.

At the very least SSO enables the originating tool and ALF to "share" the
same authentication for the original user.  In its fullest use it allows
deep authorization throughout the set of tools in use.

ALF must provide a flexible approach to security since the security needs,
goals and attitudes vary between companies and applications.  That said, I
think 3 is the most practical model in most cases but there are always
exceptions.

Tim


"Daniel Gross" <gross@xxxxxxxxxxxxxxx> wrote in message
news:disfen$i1g$1@xxxxxxxxxxxxxxxx...
> Hello,
>
> While reviewing the single sign on discussion the following question
> occurred to me:
>
> It appears that a premise underlying single sign on for service flows,
> is that the tool user upon whose action an event is raised, must have
> the authorization to access all tools that are potentially accessed in
> an ensuing service flow.
>
> Couldnt it be the case that the user upon whose behalf an event is
> raised may, due to organizational policy, not have the authority to
> access some of the tools in the service flow, which means another user's
> credentials might be necessary to complete the service flow.
>
> For example, a tester who logs an issue, may not have the authority to
> enter project managment information related to the logged issue into a
> project management tool. The testers credentials that would be passed to
> the service flow would then not authorize the automated entering of data
> in the project management tool.
>
> The single sign on assumption seems to mean that an AFL site
> administrator must ensure that for every user who can trigger an event,
>   the authority is also given to access all tools that could be called
> by a service flow.
>
>
> Alternatively, raising the issue of roles in ALF, could it be the case
> that an ALF administrator may define and pass his/her credentials to
> access all relevant tools that are called by an ALF service flow.
>
> appreciating any comments,
>
> Daniel