[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[alf-dev] Reviewing Single Sign On discussions
|
Hello,
I am currently summarizing some of the design discussions about
authentication and single sign on, and was wondering if someone could
perhaps provide some clarifications:
Citing from the ALF Rquirements Meeting Minutes 8/25/2005
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 enable a secure way to propagate
userid information from a tool raising an event to the service flow
that will execute as a result of an event.
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 userid propagation
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.
I was wondering, does anyone recall the key arguments why user mapping
should not be a job of ALF, and why maintaining a credential cache is
only associated with user mapping between tools.
appreciating any comments,
Daniel
ps. Althoug its still quite preliminary i am including a partial summary
of the authentication discussion, as it appears to me reflected in the
currently available documents:
ALF: high level design goals relevant to authentication
-------------------------------------------------------
1. Any authentication solution should enable (or at least not hinder) to
maximize the number of tools adapted for ALF, as well as accelerate the
adoption. Some guiding principles to achieve these goals are to:
a. minimizing changes needed to ALF enable a tools
b. minimizing design and implementation complexity to ALF enable a tools
2. Any authentication solution should aim to utilize standard based
design solutions, where possible.
Design requirements/constraints under which an authenication solution is
considered:
-----------------------------------------------------------------------
From a tool/tools vendor point of view:
1. It is assumed that prior to providing a services, a tool may requires
a user to first log-on
2. If log-on is required then, it can be performed either:
a. manually or
b. the tool provides a programmatic log-on facility,
c. or a tool can be compatible with an existing centralized identity
manager such as LDAP, CAS, or JOSSO, in which case log-on could be
performed by passing a credential ticket together with the service request.
3. a tools vendor who considers adapting a tool to work with the ALF
environment may:
a. not be willing to make any changes to the already existing log-on
facility.
b. may be willing to support a programmatic user id and password log-on
via its web-service based interface.
c. may be willing to include support for particular credential based
centralized single sign-on solution
d. may to some extent be willing to adapt/enhance the tool to support
ALF custom solutions for authentication.
2. It is assumed that an ALF site administrator when using ALF
a. may want to have a single sign on solution available that can be used
"out of the box"
b. may want to continue use a centralized identity manager already in
use in his/her organization
c. may be willing to adopt a light-weight solution where predefined
user-id's and passwords are pass around.
Possible design approaches for ALF
-----------------------------------
1. ALF provides a fully integrated SSON authentication service, where
ALf may:
a. custom build a solution
b. utilizing an existing implementation such as CAS or JOSSO
2. ALF provides a credential store in which during runtime credential
information obtained from outside can be stored and retrieved by ALF
enabled tools.
3. ALF only passes user id and passwords around in a secure way. ALF
enabled tool users need to ensure that all tools called within a
predefined service flow are configured with a consistent (same) passwords
4. ALF does not manage user id and passwords and requires a SSON
solution, and thus assumes that SSON is automatically taken care of
during the execution of a service flow.
5. ALF does not manage user id and passwords, and assumes that all is
taken care of from the outside, possibly in a manual way, during the
execution of a service flow
6. ALF provides an SPI interface that enables an ALF site manager to
implement centralized user mapping. If configured, the SPI would be
called by the ALF (either the broker or while executing a service flow),
to determine the corrent credentials/userid-password to pass to a tool
invocation.
Part of my next investigation is to determine what the tradeoffs of each
of the above design approaches are ...
