Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] Registry: Need for two, Need for factory config, 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.  
 
 
Duane
 
 
>>> 

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:
xri://@eclipse*higgins/idas/contextprovider/<some other stuff>
http://higgins/idasProvider/jndi/<some ( http://higgins/idasProvider/jndi/%3Csome ) other stuff?>
@higgins*idas?_xrd_t=http://jndi/ldap/corp_dir
 
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
 
Jim


>>> "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  ( http://wiki.eclipse.org/index.php/IdAS_Registries_Proposal#IdASContextRegistry )later.  I think it just refines what's there right now.

 

Jim

Back to the top