[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [alf-dev] Authentication and Single Signon
|
Hello Tim,
Thank you for your comments. I guess my thinking in relation to trust
was as follows:
It appears to me that a main concern of a ticket-based single sign-on
solution is that secondary domains or applications that need logging on,
should not be presented with the primary credentials (userid/password
that were used during a first log-on). Rather than primary credentials,
secondary domains/applications are rather presented the ticket/token,
which in turn be authenticated by the secondary domain/application at a
trusted identity server.
This reasoning lead me to think that if ticket-credentials are used
within ALF to implement single sign on, rather than to configure and
propagate the primary credentials of users (userid/password), the reason
would be that ALF does not necessarily trust ALM applications it
orchestrates in providing them with primary credentials that are valid
for other ALM tools also.
If trust is not an issue, it appears that the authentication and audit
requirement could also be met by configuring and propagating
user-id/password information of users, to any tool that requires these.
BTW, the recent clarifications that Shaw made during the last conference
call changed my understanding of when it most makes sense to utilize
SSON. There are however some issues i haven't figured out yet, and will
hopefully soon post some clarification questions ...
appreciating your comments,
Daniel
Tim Buss wrote:
Daniel,
Thanks for this analysis. I like the breakdown though I differ somewhat
on your conclusion.
The motivation for Single Sign On is really to allow the various
independent tools to authorize and audit access by specific users to the
entities managed by that specific tool. While this does represent a
trust issue, functionaly it is about enforcing "trust" between the user
and the corporation that owns the entity and no so much about the
technical issue of trust relationships between ALF and the various
tools.
Thus, rather than the necessity of SSO, the issue is more the difficulty
in achieving it. If it cannot be achieved as a whole what alternatives
can we support that will get us part way there. In these compromises,
trust between ALF and the tools does then becomes center stage since,
generally, these compromises reduce the specificity of the credential
supplied to the tool. It may be that there is no credential at all. At
that point, while it may still be possible to secure the tool, the tool
will be wholy reliant on ALF to guard against unauthorized access and
must trust that ALF is only accepting authentic and authorized requests.
This implies, I think, a need for ALF itself to provide some mechanism
for authentication and authorization around the actions taken as a
result of an event. We will explore this more once we get past the POC
and begin to focus on the security.
Tim
-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx]
On Behalf Of Daniel Gross
Sent: Thursday, November 10, 2005 10:49 AM
To: alf-dev@xxxxxxxxxxx
Subject: [alf-dev] Authentication and Single Signon
Hello,
After a pause I am finally getting back to looking at ALF security.
It appears to me that the discussion as to what "cross-tool"
authentication mechanisms to offer depends on the context, i.e. usage
scenarios, within which ALF is intended to be used.
Following are several usage scenarios that came to mind. I am wondering
which one are intended to be supported:
ALF installation site
---------------------
A1. ALF is locally installed and used by a single user on his/her
workstation
A2. ALF is installed on a server and is used in an organizational
context.
A3. Several ALF instances are used some installed locally others
centrally on a server.
ALM Tool location
-----------------
T1. ALM tools are installed locally and used by single users T2. ALM
tools are installed on central servers within an organization and used
by many users T3. ALM tools are installed on 3rd party vendor sites and
accessible across firewalls
Tools security needs
--------------------
S1. ALM tool requires authentication
S2. ALM tool does not require authentication
User trust level
----------------
Tr1. ALM tool user trusts ALM tool (providers) and is willing to submit
user id and password Tr2. ALM tool user does not trust ALM tool
(providers) and is only willing to pass ticket-based credentials, that
can be authenticated centrally.
It appears that only within a usage environment of (A1) single sign on
makes most sense. I.e where ALF is installed locally at one users
workstation, and is orchestrating local as well as centralized tools.
In all other cases either providing a managed multi-user sign-on
solution or having a "configured" ALF user (as mentioned by Tim in a
previous posting), whose credentials are always used for tool sign-on
when called from within an ALF service flow, makes sense.
The issue of whether there is a need for a central authentication
service seems to depend on the trust level (Tr1) or (Tr2). If trust is
given then ALF can pass along userid and passwords, otherwise ALF may
want to provide, or at least passing along, credential tickets from a
centralized authentication service.
appreciating any comments,
Daniel
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
**********************************************************************
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.
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev
