Jim,
With
some apprehension (being a newbie to this group, and all) I will add my $0.2.
Considering
XRI resolution as a metadata discovery framework, this universe consists of XRI
"resources" whose XRI identifiers can be resolved into their XRD
metadata.
Certainly
the XRD structure is a tad "biased" toward describing metadata in
terms of the endpoints of different types of servers. In our network-based
reality, "I have server endpoints and therefore I am". This is why a
primary metadata construct of the XRD is the <Service> -- which we
generally refer to as a "service endpoint" or SEP. [As we all know
the “X” means extensible, so the XRD can also contain any type of
metadata.]
So
Paul's point about server endpoints -- the (a) type of metadata -- belonging in
XRDs is certainly in keeping with this XRD bias. I should point out though that
in the most common existing use case -- that of XRI resources representing
human beings and organizations -- the resource does not represent a server and
its endpoints as much as it represents, for example, a human and each of its
different types of servers.
One
could certainly conceive of modeling a user-entity-thingy as an XRI resource
(giving it an XRI identifier) and then having its resource metadata contain
things like context (data source) configuration. One advantage would be that
XRI resolution becomes a standardized means of obtaining resource metadata.
But as
we all know, just because one can do it, doesn't follow they should do it. I
will leave it at that. J
Jim
wrote:
>
Right, in talking with Steven and Andy at ootao, they said that there are ways
of securing > this kind of information (as far as I understood).
Yes,
since XRI resolution involves delegated resolution authorities, even global
resolution can result in XRDs that are only available on an internal network
(or single machine.) For example, anyone's XRI resolver can resolve
=steven.churchill*hobbies, but I can make it such that
=steven.churchill*private*ootao can only be resolved from inside my private
network. I do this by placing a vanilla XRI resolver on my local network (which
still resolves globally) but I place the authority resolution service for
="" on a private endpoint or localhost. This authority
resolution server is in effect the “registry” containing the
configuration metadata.
~ Steve
From: Jim
Sermersheim
Sent:
Wednesday, February 21, 2007 9:46 AM
To: higgins-dev@xxxxxxxxxxx
Subject: RE: [higgins-dev]
Registry: Need for two, Need for factoryconfig, and cpid format
Right, in talking
with Steven and Andy at ootao, they said that there are ways of securing this
kind of information (as far as I understood).
Jim
>>> "Duane Buss" <DBuss@xxxxxxxxxx> 2/21/07 10:34 AM
>>>
The desire to co-locate all the configuration information in one registry
does have potential security ramifications. I can envision
cases where the STS or IDAS CPs have configuration information which must be
kept secure, for example a Least Privileged user/credential for reading
information from a JDBC or LDAP Store.
From:
|
"Jim
Sermersheim" <jimse@xxxxxxxxxx>
|
To:
|
<higgins-dev@xxxxxxxxxxx>
|
Date:
|
02/21/07 8:26 AM
|
Subject:
|
RE: [higgins-dev]
Registry: Need for two, Need for factory config, and cpid format
|
CC:
|
<steven.churchill@xxxxxxxxx>
|
I think as
I read this I get some of the terms mixed up (especially the e.g. stuff in
parens in the description of a -- looks like "server" stuff but comes
right after "client).
Maybe it
would help me if we used as an example something we're doing today -- that is,
the STS pulls a cid out of an RST and from that, we eventually end up with an
instance of IContext, where that IContext comes from the JNDI IdAS
provider and represents data in a specific LDAP store. After we get
past that, we could talk about how the IdP (STS) creates the cid and puts it in
the CardSpace card (maybe in a followup email).
What would
the cid (as an xri) look like? I'm not sure. It seems like there
are a number of ways to do it, but in the end I think we still agree that the
cid must be ultimately capable of consistently producing an IContext
instance. Some stabs in the dark might be like:
where
<some other stuff> must be something that is used for differentiation
such that a specific context may be identified.
Assuming
we get this right, the STS would make use of something in IdAS to resolve that
cid to an XRD containing a single <service> element. In that
<service> element, there is a <Type> element containing some URI
which is said to:
- be
made up of a "protocol" and "api"
-- where
"protocol" is interpreted as ? in this example
-- where
"api" is interpreted as ? in this example
- is also
used to associate the contents of this <service> element to some
context-specific data in an "other" registry.
Not
knowing what the ?'s are above, I'll make something up like: http://jndi/ldap/corp_dir so it will match
the third xri example above.
Using http://jndi/ldap/corp_dir (found in
the <type> element), the STS uses a different IdAS API to locate the
config data in the other registry which will enable it to create an instance of
IContext.
So,
filling in the blanks above would probably help me understand a little better
what you're thinking.
But back
to the point of server/service versus client: The driving factor causing
us to want to co-locate all the information in one registry is to prevent
administrators and other IdAS users from having to deal with two different
registry/config metaphors. What sold me on using XRI/XRDS in the first
place was that it seemed to have already solved the problems of
registration/resolution/configuration. This proposal leaves us with the
task of inventing another registry/config file format and resolver for
information needed by the "client".
I also
wonder what the security/level-of-control ramifications are of separating the
"server" from the "client" in this way. Today, a
deployment like the example above co-locates the "server" and
"client" config such that the person deploying it is in complete
control of what (contexts) the service is allowed to produce. Meaning,
the deployer can set up a context to point to one and only one LDAP
server. Drawing the proposed distinction means that the deployer must
make sure that the "client" is controlled and well-behaved -- this
may end up being nothing to worry about.
Anyway, if
we can get on the same page with the stuff above, we should move on to:
- How the
deployer of the above scenario updates the XRDS and the "other"
registry
- How the
STS discovers the cid(s) which can be used when generating cards
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 2/19/07
4:41 AM >>>
Jim,
I've been thinking about this problem independently of your email
below. Let me share what I'd come up with first and then relate it to your
preferred proposal #4.
I see two kinds of information "server" and
"client"
(a) Information about a Context available on this server and what
protocols this "server" supports that can be used to access it by a
"client" (e.g. IdAS (e.g. an LDAP backing store, an OpenID
"OP", or a PeopleSoft database) as identified by a ContextId (aka
"cid"). [Note: with the xri resolver code that we envision
using, there is a way to configure the "root" server URL so that this
registry can be on the net, on a LAN or on localhost].
- network endpoint <URL> [required]
- Protocol and API (conflated): <type>
[required]
- Service type: that conveys the following semantics
(I think we need something more structured than today's XRDS <type>
element. We might want to propose these additional XML elements to XRDS):
- metamodel: (e.g. HOWL, OWL, SQL) [required]
- schema: (e.g. Novell-HR-dept-directory) [optional]
- label
(e.g. "Corporate
Directory") [optional]
(b) Information describing how to identify and configure a client
(Context Provider) to gain access to a). This would include:
- ContextFactory java class name
- <ContextFactory-specific config data>
- <Context-specific config data (e.g. auth
materials and other stuff)>
To me:
·
(a)-type (server-related) information belongs in an XRDS document
(preferably globally accessible) discovered by resolving a ContextID [registry
#1].
·
(b)-type (client-related) information belongs <somewhere>, is
managed by "IdASRegistry" [registry #2], and is looked up by
Okay, now on to your email...
We're in agreement on the need for two registries.
You propose using your new CPID element to bind (a) to (b) type
information. Instead of <CPID> I propose we use the <type> element
to bind (a) to (b). The value of <type> is an XRI that indicates both the
protocol to use and the API of the service. So the values are things like
"http://openid.net/server/2.0" or "http://opensql.org/sql92"
that represent (HTTP protocol with the OpenID API) and (SQL protocol with SQL
API) respectively.
The new element metamodel (the
optional schema) mentioned under
(a) above to the <Service> block will enable a Context Provider to know
if it really could open this Context (i.e. that there really is (or could be)
Context data there). The label
could also be useful.
You proposed that (b)-type (client-related) information is stored
in another section of the same XRDS document. I don't agree. The (a)-type
information is an advertisement of services available at on the server. These
might include Higgins-related
services (e.g. serving up a Higgins
Context), but this might sit alongside an OpenID OP or a SAML attribute
service. The (b)-type information is not related to the Context server-it is
information required by a client. So I think that the (b)-type information
belongs in a separate registry.
-Paul
From: higgins-dev-bounces@xxxxxxxxxxx
[mailto:higgins-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jim Sermersheim
Sent: Thursday, February 15, 2007
9:13 PM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Registry:
Need for two, Need for factory config,and cpid format
We came up
with a non-contrived example today of why a context factory would need some
config data. A context provider which produces contexts that are backed
by non-local data may want to build a pool of reusable and/or shared
contexts for purposes of connection pooling and sharing. The pool/sharing
logic makes sense to happen in the CP's factory, and would need to be
configurable. Therefore, we see a need to pass configuration data to a
factory when it is instantiated. Furthermore, we see use cases where an
application might need to adjust this configuration at a later point (I'll talk
to that point later).
We looked
at three possibilities of where a context factory's config data might be
placed.
1) It
could be placed with the application (i.e. the application could have a config
file and in that config file, we could list all the config data for all
factories that application might ever use. We didn't like this due to the
manageability problems it would likely create.
2) It
could be "registered" in the "IdASRegistry" along with the
factory that it belongs to. We didn't like this because it precludes the
ability to instantiate multiple instances of a factory, each with different
config data, plus it increases the number of locations which hold config data.
3) It
could be located with the cpid in the context's service element in the XRDS
document. We didn't like this due to the foreseen duplication of config
data across context services.
4) It
could be represented as another service in an XRDS document. It could
have a type like "Higgins IdAS Context Factory, JNDI". We liked this,
because it continues to use the XRDS metaphor, but de-couples the
factory+factoryConfig service from the context service. There would be an
element in the context service which points at a factory+factoryConfig
service. In other words, a (or a number of) context service sections
could reference a context factory service section.
Imagine
something like (the actual values are invalid made up junk at this point):
<XRD> <Service>
<Type>Higgins IdAS Context, JNDI, Corporate Directory</Type>
<CPID>Higgins IdAS Context Provider, JNDI, Pooled</CPID> ... other config data necessary for a Higgins JNDI/LDAP CP to connect to open this Context. </Service> <Service> <Type>Higgins IdAS Context, JNDI, Home Directory</Type>
<CPID>Higgins IdAS Context Provider, JNDI, Pooled</CPID> ... other config data necessary for a Higgins JNDI/LDAP CP to connect to open this Context. </Service> <Service> <Type>Higgins IdAS Context, JNDI, Address Book</Type>
<CPID>Higgins IdAS Context Provider, JNDI, Default</CPID> ... other config data necessary for a Higgins JNDI/LDAP CP to connect to open this Context. </Service> <Service> <Type>Higgins IdAS Context Provider, JNDI, Default</Type>
<CFClass>org.eclipse.higgins.idas.cp.JNDIContextFactory</CFClass> ... other config data necessary to configure the JNDIContextFactory. </Service> <Service> <Type>Higgins IdAS Context Provider, JNDI, Pooled</Type>
<CFClass>org.eclipse.higgins.idas.cp.JNDIContextFactory</CFClass> ... other config data necessary to configure the JNDIContextFactory (i.e. max pool size, idle timeouts, etc). </Service> </XRD>
Assuming
we can do something like that (I'm pretty sure we can in spite of the way I've
botched up the identifiers), then the work flow would go something like this:
- Resolver
turns the cid into a contextSEP.
- From the
contextSEP, <something> gets the CPID and resolves to the providerSEP.
- Using the
providerSEP, the IdASRegistry can produce and configure an instance of
IContextFactory.
-- We
believe it's a good idea that the IdASRegistry would only return a single
instance of IContextFactory for any given CPID (which is the <Type> in
the providerSEP). Thus the IdASRegistry would have a table of {key,
value} where key = CPID, and value = IContextFactory instance.
- From the
IContextFactory and contextSEP, <something> can produce an instance of
IContext.
An
existing IContextFactory instance could be re-configured not by the
IdASRegistry, but by the application at any time via a call to a method like
IdASRegistry.config(XML)
Anyway, it
seems there *is* a need for two registries (though I see IdASRegistry as
really just a way to manage factory instances at this point -- so not sure
"registry" is the right term), a need for factory config, and there's
a proposal for a cpid format.
On the
subject of what in the "Higgins IdAS Context Provider" service is
used to instantiate a factory instance -- I think this setup might help address
Valery's concerns with eclipse extension IDs. Meaning, we could put
different (or multiple) things in there which could be used to this end.
Unless
there are problems with this, I'll try to move the contents of this mail over
to the wiki
later. I think it just refines what's there right now.
|