[higgins-dev] Contexts from Multiple Identity Sources (was [IdAS] use ca

["Tom Doman" <TDoman@xxxxxxxxxx>]

I agree that the programmatic user of a Context doesn't care about the
underlying bits.  That's fine, but the configurator cares and the
Context Provider implementor cares how to hook these disparate system
together into one coherent Context.  I suppose I'm belaboring it now,
but that's the understanding I'm trying to get.  BTW, from what we've
all said so far, I assume we're in agreement that the programmatic user
of a Context may care about where the bits are coming from.

Here's my use case:
1. There are three Identity sources from which to obtain Identity
information.  Two different LDAP stores and an SQL database.
2. The Identity information may be wanted from a single Identity
source, or any combination of Identity sources, including all of them
simultaneously.

Here are my questions:
1. Do I need a Context Provider for each individual identity source
plus any combination I might want?  Should I only have one Context
Provider for all and have separate Contexts for each combination of
Identity sources?  Something else?
2. To provide a consistent data representation at the highest level of
the Context, I'll need to map names, attributes, requests, etc. for each
identity source.  Some of those identity sources could use the same code
to do this based simply on configuration where the sources may differ in
schema, etc (such as the two LDAP sources in this use case).  Would
these name, attribute, and request mappers be another in a line of
Context Providers or Contexts in between the highest and lowest level
Contexts?

Thanks,
Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 7/20/2006 1:48 PM >>>

Caveat: I'm still rather new to this, also, so take the following 
explanations with
a grain of salt, and correct me as needed.

Tom Doman wrote:

>1. I guess I had thought of Context Providers as being providers of a
>specific kind of context.  For example, an LDAP Context Provider that
>provides Contexts to LDAP endpoints or a Join Context Provider that
>provides Contexts to other Context Providers which, say, join data
from
>LDAP, SQL, and Liberty endpoints.  How far off the mark am I here? 
Some
>of what was discussed on the call as well as these use cases seem to
>indicate that any given Context Provider can provide a Context to the
>same URI.  And perhaps the Context Providers then are just different
>vendor implementations of how to get a Context for a given URI.  I'm
>sure much of my thinking is guided by what we've implemented in
Bandit
>and I'll send the promised examples under separate cover.  I went
>through the Java Docs yesterday but I'm still unclear on exactly what
>Context Provider and Context are.  In addition, as per #2 below, how
>they can be used to encapsulate or join a variety of disparate data
>sources and data formats.
>  
>
"Does a Context Provider specify a type or a vendor?" I think the
answer 
is, "Both."
 
A Context is a technology-neutral concept.  It contains a set of
digital 
subjects, and the
things that it can represent are described by its schema.  But at the 
Context level,
nobody cares whether the underlying bits are in an LDAP directory, or a

text file,
or an SQL database.  It's the ContextProvider's responsibility to 
translate the bits
in the repository to the form that can be used as a Context. 

So, the Context Provider certainly needs to know what the storage
technology
is and how to use it.  It could also source data from many different 
formats, presenting
the results as a unified Context with a specific schema.

But the Context Provider also represents a specific vendor's (or
author's)
code to implement that transformation.  So it's possible to have a 
Novell-LDAP
provider and an IBM-LDAP provider. 

I think I muddied the waters with my explanation of the Provider class

as used
in the Java Crypography Architecture.  In that case, a Provider 
represents a particular
implementation of some set of JCA services, which might be digital 
signature,
encryption, message digest, etc.  A Provider can implement any or all
of 
these
services.  So I was thinking that the "IBM" Provider, for example,
would 
include
many different types of Context Providers that we've been talking
about, 
each with
different underlying technologies -- LDAP, RDF, SQL, or some custom 
combination
of these. 

Now, if I follow Tony's logic correctly, I think we're back to equating

Provider
(in the Java sense) with Context Provider (in the Higgins sense).  In 
other words,
each Provider has a specific way that it provides access to Context 
data.  And if
there is a need for different kinds of tranformations, because of 
different underlying
technologies, then a vendor may have several different Providers, each

serving
a particular need.  An attribute could be associated with the Provider

that tells
which underlying technology (or technologies) it supports.

>2. Use case number 4 makes me wonder what it means to "import a
>Context" but I assume that'll become clearer in Greg's description. 
It
>does, however, raise an additional use case I'd like to see added and
>detailed.  That is, the case where the user wants a Context which
>gathers identity data for a variety of data sources, each of which
may
>have data represented in a distinct specific format (e.g. LDAP, SQL,
XML
>File, etc.).
>
>  
>
What I mean by "import" is the following.  Suppose that my company has
a 
pre-existing
LDAP directory with information about all my employees.  I want to make

that information
available to the Higgins framework.  I don't want to implement my own 
LDAP-based Context
Provider.  Instead, I look at the Providers available on my system, 
check whether any of them
supports an LDAP backend, and then I do whatever configuration is 
necessary to make my
data available as a Context (or a set of Contexts) via that Provider.

>3. A clarification on what end points are would also be helpful.  
>
My understanding of IdASEndpoint is that it's the "place" where a user

goes to initiate
interaction with one or more Context Providers.  It's the top-level 
interface to the IdAS.
Jim has pointed out that "endpoint" might not be the best name for
this, 
and I don't
disagree. 


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev