Re: [higgins-dev] Digital Identity and IContext open() method

[Nataraj Nagaratnam <natarajn@xxxxxxxxxx>]

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

"Tom Doman" <TDoman@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

07/28/2006 04:13 PM

Please respond to
"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>

To	"Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx>
cc
Subject	Re: [higgins-dev] Digital Identity and IContext open() method

Like I say, I like the direction, it just leaves some
doubts in my mind about how it's done agnostically if the consumer doesn't
know there's a set of choices it can count on.  In your LDAP example,
there are two simple name & pw and SASL.  The end user and the
"consumer" equivalent know how to do those whether the "provider"
equivalent supports them or not.  So, I think my question remains,
namely, can or should we agree on a required set, recommended set, extended
set, etc. of AuthN methods that Higgins Context Providers should support
so that consumers can choose which to support and convey through to their
end users when they implement to Higgins?

Yes, I'd also like to talk more about how a consumer discovers as well.

Tom

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 7/28/2006
1:21 PM >>>
I disagree with the notion that it's hard to write the authN code in a
service-agnostic LDAP application.
 
LDAP let's me first choose between Simple name & pw, and SASL mechanism,
and there's a method to discover the supported SASL mechanisms. So the
application knows how to deal with some number of SASL mechanisms, matches
the one it wants with the server's capabilities and goes.
 
I *think* Greg is pointing in the same direction. Consumer discovers the
supported AuthN type(s), decides which type it wants to use, creates that
and calls open.
 
One difference between the two models is that the notion of SASL mechanisms
is standardized. If we agree that Greg is on the right track, we need to
talk more about how a consumer discovers (by reading policy) the supported
AuthN type(s) and makes a determination as to the type of Java Object that
must be created.
 
Jim

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 7/28/06 11:15
AM >>>
I kind of like where you're heading but I'm not sure I'm ready to agree
or disagree.  Mark me down as a temporary abstention. :)

I still fear we're heading to a place where every provider will do
things so differently that no consumer of the IdAS service will be able
to use implemented Context Providers freely because they'll be so
different in this and other regards (such as uniquely identifying a
Digital Subject as I mentioned in earlier e-mails).

For this particular issue, I wonder if we should define interfaces for
some of the common AuthN methods (user name\password, SAML, Kerberos,
etc.) so that consumers have a small, known set of methods they can
count on Higgins Context Providers to have implemented.  The same
thing
would apply to name forms I talked about earlier where the ECF nameform
extension may come in handy.

I look at LDAP and see that they defined the protocol but schema
differences and AuthN methods makes it hard to write a LDAP directory
service agnostic application.  Maybe this is an extension of Higgins
or
a separately scoped area that will warrant some cross-project or
additional project work.  I guess I'm looking for additional opinions
as
well Greg ... anyone?  Buehler?  :)

Tom

>>> Greg Byrd <gbyrd@xxxxxxxx> 7/28/2006 8:32 AM >>>

>
> So by 'provider' I was just referring to the extension that
implements 
> the Namespace extension point...simply a provider for creating ID
> instances of arbitrary type.  

I understand.  I'm just claiming that IdAS should not have to provide
code to create the tokens needed to authenticate to Contexts.  It's
the

consumer's responsibility for creating this token, and it's the 
Context's responsibility to tell the user what it needs (via the 
policy).  If the consumer uses a Namespace ID extension, that's fine
--

but that's code that lives on his side of the interface, not ours. 
(I'm 
hoping someone else will jump in a agree or disagree with me on this.)

> I have to admit I'm still a little confused by the current use of
the

> term 'provider' WRT the Higgins model.  Given the recent discussions

> it's not at all clear to me what the sequence of operations is for
> creating/using an IContext with a real use case.  Could someone
point

> me to example and/or junit test code that uses the API in current
> expected/proscribed manner?
>

Let me give it a try:

(1) Consumer of IdAS service (aka User) needs to get a particular 
Attribute value for a particular DigitalSubject, and he has the URI of
a 
Context that is likely to provide the required value.

(2) User contacts IdAS service and finds a ContextFactory that can 
handle this URI.

(3) User asks the ContextFactory to create an IContext.

(4) User queries the Context's policy (IContext.getPolicy) to determine

what credentials are needed to open it.

(5) User calls IContext.open to authenticate to the Context and gain 
access to its data.

(6) User searches for DigitalSubject  (IContext.getSubjects) and 
retrieves desired Attribute value (IDigitalSubject.getAttribute).

(7) User calls IContext.close to terminate use of the Context.



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