Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Context Discovery"

(Use case #1 details)
m (Added tag for left menu)
 
(108 intermediate revisions by 3 users not shown)
Line 1: Line 1:
===Design Goals===
+
{{#eclipseproject:technology.higgins}}
In addition to all the previous design goals, here are some more that were behind this proposal
+
== Intro ==
* '''Higgins-ism free.''' Higgins is not in the service/protocol definition business. So the intuition here is that there shouldn’t be any higgins-isms in the XRDS documents. And there should be nothing special about how ContextIds are resolved to XRDS Service blocks
+
This page explains the process for [[Context]] discovery in the [[Identity Attribute Service]]. Note that this page only provides a general descripion and examples of the process. For specific implementation details, see:
* '''Simple things are simple.''' We want an approach where a OpenID XRI (or URI) can be referred to by a Higgins i-card using a ContextId of the same value as this XRI (or XRI) and presented as an IContext without any modification of the XRDS to which the OpenID XRI resolves. In other words, armed only with an OpenID XRI/URI, the Higgins Identity Agent should be able to present its attributes to the user (read-only) in the i-card manager. OpenID servers don’t need any contextConfig or factoryConfig to use them.
+
* '''Complex things are possible.''' Beyond the simple OpenID case, we also want to support LDAP, SQL, etc. backed Context which do need contextConfig and probably factoryConfig metadata in order to be presented as an IContext.
+
  
===Use Cases===
+
* [[Context Discovery Components]] for a description of the components that have been implemented for context discovery.
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
+
* [[ContextId]] --the formal ABNF definition
|-style="background:#d6dee9; color:black"
+
! width="5%" border="1" align="left" valign="top" |
+
! width="10%" border="1" align="left" valign="top" | Use Case
+
! width="10%" border="1" align="left" valign="top" | ContextId
+
! width="10%" border="1" align="left" valign="top" | Resolves to
+
! width="20%" border="1" align="left" valign="top" | Finding the <Service> block by
+
|-
+
|1
+
|Higgins OpenID URI i-card
+
|=drummond
+
|xrds1
+
|matching <Type> value of "http://openid.net/server/2.0"
+
|-
+
|2
+
|Higgins URI i-card
+
|=drummond/vcard/+ldap
+
|xrds2
+
|matching <Path> value of "+ldap"
+
|-
+
|3
+
|Higgins URI i-card
+
|=drummond/webSurfingPersona/+sql
+
|xrds3
+
|matching <Path> value of "+sql"
+
|-
+
|4
+
|Higgins URI i-card
+
|@parityinc.net/AccountingDept/+ldap
+
|xrds4
+
|matching <Path> value of "+sql"
+
|-
+
|5
+
|Higgins CardSpace-interoperable managed i-card
+
|localhost/icardstore/236-86/+ldap
+
|xrds5
+
|matching <Path> value of "+sql"
+
|}
+
.
+
  
====Use case #1 details====
+
== General Process ==
User has an existing OpenID, "=drummond". They wish to manage their OP using the Higgins Identity Agent, specifcally the Higgins i-card manager. They create an ''OpenID URI i-card'' using the i-card manager. Note that this is a new specialization of the generic Higgins URI i-card. During the process of creating the new i-card the user types in their OpenID, "=drummond". This is the ContextId of the OpenID URI i-card. The user wishes to see the values of their attributes (i.e. the attributes defined by OpenID authentication) in the i-card manager. Sequence:
+
Context discovery in Higgins consists of the following four general steps:
#The OpenID URI i-card invokes an XRI resolver in an IdAS.utils package: XRI.resolveByType("=drummond", "http://openid.net/server/2.0"). The first arg is the ContextId, the second is new; it is the target service <type>. We're telling the resolver to find the <Service> block that matches by matching on <Type> with the value provided. (See XRDS Files section below to see a description of the contents of xrds1)
+
#IdAS.open searches IdASRegistry for an IContextFactoryClassName for the http://openid.net/server/2.0 service type, it finds org.eclipse.higgins.cp.openid.
+
#That factory initiates itself with the factory config elements (column 3 in IdASRegistry table)
+
#We do a <factory>.getInstance reading the “Other <Service> elements” from column 4 in XRDS Files table for the contextConfig data
+
  
====Use case #2 details====
+
# The process starts with passing the [[ContextId]] for which context discovery is needed to IdASRegistry.
User wants to view the IContext associated with a Higgins URI i-card whose ContextId is "=drummond/vcard/+ldap". Sequence:
+
# IdASRegistry uses the [[ContextId]] to obtains a context descriptor (typically an XRDS file) that contains at least one context type, zero or more URIs, and an optional configuration map.  
#The i-card manager invokes IURICard.getContext() on this i-card
+
# From the context type, IdASRegistry finds a context factory that can instantiate a context for the given [[ContextId]].
#The i-card invokes an XRI resolver: XRI.resolveByPath("=drummond/vcard/+ldap")
+
# IdASRegistry returns a context factory that has been configured.
#This resolves to the file "xrds2" and within it the service block whose <Path> element matches "+ldap"
+
#We read <Type> value of the same service block and use it in IdASRegistry to look up an IContextFactory class name
+
#Use this factory to getInstance an IContext
+
  
===XRDS Files===
+
== Examples ==
Each file provides the metadata for the ContextId to which it resolves so that a Higgins Context Provider might be found and that could be told enough about the endpoint to present it as an IContext instance.
+
  
The following table shows the elements within the matched <Service> block:
+
=== Example #1: Typing in an I-Name ===
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
+
Paul is using a version of Higgins Identity Agent that allows him to type the i-name of a friend, '''=drummond''' into his i-card manager. His i-card manager then calls IdASRegistry which performs the following steps:
|-style="background:#d6dee9; color:black"
+
# Resolves the i-name into an XRDS document to discover the service endpoints (SEPs - the <Service> blocks in the XRDS document). From a Higgins standpoint, each SEP corresponds to a Higgins context descriptor.
! width="5%" border="1" align="left" valign="top" | XRDS File
+
# Looks at the <Type> element of each SEP to discover its context type.
! width="10%" border="1" align="left" valign="top" | <Type> element's value
+
# Looks in the Context Provider Registry for that Higgins installation to see what service types are supported by this installation.
! width="10%" border="1" align="left" valign="top" | <Path> element's value
+
# Dynamically generates N i-cards -- one for each service type that Higgins understands. For example, one of the service types that this installation of Higgins understands is OpenID, and since =drummond has provisioned an OpenID service, Higgins will create a r-card is whose ContextId in ContextXRI format is '''=drummond/$context+openid'''.  
! width="10%" border="1" align="left" valign="top" | <Schema> element's value
+
! width="20%" border="1" align="left" valign="top" | Other elements
+
|-
+
|xrds1
+
|http://openid.net/server/2.0
+
|(not present)
+
|(not present)
+
|<URI>: url-of-OP</URI>
+
|-
+
|xrds2
+
|xri-for-ldap
+
|"+ldap"
+
|url-of-schema-for-this-vcard
+
|<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
+
|-
+
|xrds3
+
|xri-for-sql
+
|"+sql"
+
|(not present)
+
|
+
|-
+
|xrds4
+
|xri-for-ldap
+
|"+ldap"
+
|url-of-schema-for-this-departments-employee-directory
+
|<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
+
|-
+
|xrds5
+
|xrd-for-ldap
+
|"+ldap"
+
|
+
|<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
+
|}
+
.
+
  
Here is what the service block looks like in xrds2:
+
=== Example #2: Clicking on an R-Card ===
 +
Paul wants to view an r-card whose ContextId is '''=drummond/$context+bizcard'''. This supposedly has Drummond's business card attributes. The sequence is:
 +
# The i-card manager invokes IURICard.getContext() on this i-card.
 +
# The i-card object calls IdASRegistry.getContextFactory(contextId) to find an IContextFactory that can instantiate an IContext for the r-card's IContextId.
 +
# IdASRegistry obtains the context descriptor (in this case, an XRDS document retrieved via XRI resolution of '''=drummond/$context+bizcard''').
 +
# The context descriptor contains one or more context types, which are used by IdASRegistry to look up a suitable context factory.
 +
# The IContextFactory is returned to the i-card object, which then calls the factory's createContext(contextId) method in order to get back an IContext object for the i-card's IContextId.
  
<Service>
+
=== Example #3: Token Received by Token Service ===
    <Type>xri-for-ldap-type</Type>  <-- don't know if this is required or not, since we're matching on <Path> not <Type>
+
A ContextId, '''localhost/attstore/2386''' is stored in the metadata of the endpoint reference of the token service in the RST. It is received by the Token Service, passed to a Token Provider and used by that provider to open up an IContext using IdASRegistry. (Mike has verified that MSFT CardSpace preserves this EPR metadata so this same approach will work using Higgins or CardSpace Identity Agents.)
    <Path select="true">+ldap</Path>
+
    <URI append="none">ldap server URL</URI> ...and other ContextConfig elements
+
</Service>
+
  
See http://iss.xdi.org/moin.cgi/IserviceEndpointDefinitions for more examples of I-Service Endpoint definitions.
+
== Example XRDS Files ==
 
+
See [[ContextDiscoveryComponents]] for example XRDS files.
===IdASRegistry===
+
Maps an XRDS service type to an IContextFactory along with any factoryConfig metadata needed (if any)
+
 
+
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
+
|-style="background:#d6dee9; color:black"
+
! width="5%" border="1" align="left" valign="top" | Service Type
+
! width="10%" border="1" align="left" valign="top" | IContextFactory Class Name
+
! width="10%" border="1" align="left" valign="top" | other IContextFactory config data
+
|-
+
|http://openid.net/server/2.0
+
|org.eclipse.higgins.cp.openid
+
|??
+
|-
+
|xri-for-ldap
+
|org.eclipse.higgins.cp.jndi
+
|??
+
|-
+
|xri-for-sql
+
|org.eclipse.higgins.cp.slq
+
|??
+
|}
+
.
+
 
+
Note: "xri-for-ldap" and "xri-for-sql" as used above will be defined by the OASIS XRI TC (they will probably look like say "+i-service*(+ldap)*($v*1.0)"  and "+i-service*(+sql)*($v*1.0)"
+

Latest revision as of 08:39, 15 March 2008

{{#eclipseproject:technology.higgins}}

Intro

This page explains the process for Context discovery in the Identity Attribute Service. Note that this page only provides a general descripion and examples of the process. For specific implementation details, see:

General Process

Context discovery in Higgins consists of the following four general steps:

  1. The process starts with passing the ContextId for which context discovery is needed to IdASRegistry.
  2. IdASRegistry uses the ContextId to obtains a context descriptor (typically an XRDS file) that contains at least one context type, zero or more URIs, and an optional configuration map.
  3. From the context type, IdASRegistry finds a context factory that can instantiate a context for the given ContextId.
  4. IdASRegistry returns a context factory that has been configured.

Examples

Example #1: Typing in an I-Name

Paul is using a version of Higgins Identity Agent that allows him to type the i-name of a friend, =drummond into his i-card manager. His i-card manager then calls IdASRegistry which performs the following steps:

  1. Resolves the i-name into an XRDS document to discover the service endpoints (SEPs - the <Service> blocks in the XRDS document). From a Higgins standpoint, each SEP corresponds to a Higgins context descriptor.
  2. Looks at the <Type> element of each SEP to discover its context type.
  3. Looks in the Context Provider Registry for that Higgins installation to see what service types are supported by this installation.
  4. Dynamically generates N i-cards -- one for each service type that Higgins understands. For example, one of the service types that this installation of Higgins understands is OpenID, and since =drummond has provisioned an OpenID service, Higgins will create a r-card is whose ContextId in ContextXRI format is =drummond/$context+openid.

Example #2: Clicking on an R-Card

Paul wants to view an r-card whose ContextId is =drummond/$context+bizcard. This supposedly has Drummond's business card attributes. The sequence is:

  1. The i-card manager invokes IURICard.getContext() on this i-card.
  2. The i-card object calls IdASRegistry.getContextFactory(contextId) to find an IContextFactory that can instantiate an IContext for the r-card's IContextId.
  3. IdASRegistry obtains the context descriptor (in this case, an XRDS document retrieved via XRI resolution of =drummond/$context+bizcard).
  4. The context descriptor contains one or more context types, which are used by IdASRegistry to look up a suitable context factory.
  5. The IContextFactory is returned to the i-card object, which then calls the factory's createContext(contextId) method in order to get back an IContext object for the i-card's IContextId.

Example #3: Token Received by Token Service

A ContextId, localhost/attstore/2386 is stored in the metadata of the endpoint reference of the token service in the RST. It is received by the Token Service, passed to a Token Provider and used by that provider to open up an IContext using IdASRegistry. (Mike has verified that MSFT CardSpace preserves this EPR metadata so this same approach will work using Higgins or CardSpace Identity Agents.)

Example XRDS Files

See ContextDiscoveryComponents for example XRDS files.

Back to the top