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

["Tom Doman" <TDoman@xxxxxxxxxx>]

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