[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] Digital Identity and IContext open() method
|
Considering the delegate-pattern that Raj described...
What does this mean: "IdAS needs to understand how to connect to the
backend"?
Since this will be done as part of the open operation, it will involve
code supplied by the Context Provider (i.e., as part of the class that
implements IContext). If that Provider knows that its Contexts will be
front-ending other Contexts, then the Provider knows that it must
provide code to authenticate with those backend Contexts. The extent to
which it is flexible in terms of the types of tokens it can supply is up
to the Provider.
So I still see this as an implementor's issue, not necessarily something
that must be defined addressed by the API, except to the extent that we
provide a way to pass a credential into open.
Likewise with the issue of authenticating the end application in this
case. The CP decides how to do that and supplies code accordingly. We
do have setPolicy/getPolicy methods on IContextFactory now -- is this
something we should exploit to authenticate to the Factory before
creating a Context? Alternatively, I could see this application
implemented by IContext during open, just as we have it now. (The
Factory can copy its policy into the Context as it is created.)
...Greg
Nataraj Nagaratnam wrote:
I think I agree AND disagree - agree that the identified pattern is
applicable; disagree if that is considered the only option though.
here is where i am coming from ...
One design aspect that *may* be overlooked in this discussion is the
fact that IdAS should evolve into a service that can be remoted
deployed. In that case, connecting to IdAS can be dealt with in ouple
of ways. Let me use couple of terms like delegate-pattern and
passthrough-pattern to get the point across and those terms are not
normative for now.
* delegate-pattern - where IdAS service endpoint authenticates
the application request using its local registry of valid
subscribing users/applications, and the acts on behalf of the
requesting application (using application-id to connect to
backend datasource like LDAP)
* passthrough-pattern - where IdAS service endpoint is a mere
pass-through and it passes the supplied credentials to one of
the context providers, and thus connections is handled accordingly
From discussions below, requiring the applicationcode to supply
correct credentials based on Context/ContextProvider (and data
source?), fits passthrough-pattern. I don't think that is the only
one. In order to accomodate delegate-pattern, following needs to happen:
* application supplies right creds to IdAS based on IdAS' policy
for a given Context
* IdAS in turn connects to other context providers (one of which
can be another IdAS instance), .. and may use its own identity
to retrieve information. In this case, you may have a single
Context federate across multiple data sources to retrieve
information. Thus, application may need to connect to IdAS (acts
as a mediating gateway) under a set of creds IdAS (using its own
store, or one of the stores to validate the creds) understands.
How IdAS connects to backend data sources (e.g, LDAP, DB2,
file, etc) can be hidden by IdAS from the application. This
requires that IdAS need to understand how to connect to backend,
based on those policies, and canot be completely dependent on
the calling mechanism.
So, I think we should allow for both to happen
-Raj
[...]
