Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Authentication Materials"

(added "name+private key" authentication materials)
 
(24 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 
== About ==
 
This page describes the concept of [[Authentication Materials]] used in the [[Context Data Model 1.1]]. [[Authentication Materials]] are needed to open a [[Context]].
 
  
== Current Situation ==
+
This page describes the concept of [[Authentication Materials]] used in the [[Context Data Model 1.1]]. [[Authentication Materials]] are needed to open a [[Context]]. For example, in the case of opening an LDAP Context, a username and password may be required.
Currently, IdAS authentication materials in the IContext.open() call are defined to be just a java.lang.Object. This gives maximal flexibility to [[Context Provider]] implementations.
+
  
== Goals ==
+
Authentication Materials are classes which implement the IdAS '''IAuthNMaterials''' interface. This is only a marker interface without methods.
We would like to be able to do the following:
+
* Have identifiers for common types of Authentication Materials
+
** This is needed in scenarios when you do not know a priori what type(s) of [[Authentication Materials]] a [[Context]] accepts.
+
** For example, for [[R-Card]]s we use [[UDI]]s to point to Higgins [[Context]]s and [[Entity]]s. When a [[UDI]] is resolved, we need to know what type of Authentication Materials is needed for opening the Context it points to.
+
* (De-)serialize a concrete instance of Authentication Materials (e.g. to/from XML, String, etc.)
+
** This is useful in scenarios in which you send Authentication Materials over the network, e.g. in IdAS REST interfaces such as http://code.bandit-project.org/trac/wiki/OTIS and the [[XDI Engine]].
+
  
== Proposal ==
+
== Authentication Material Types ==
The proposal is to do the following:
+
 
* Define the following identifiers for common types of Authentication Materials:
+
In certain situations, it is helpful to have identifiers for common types of Authentication Materials:
*# urn:higgins:authmethod:1.0:usernamePassword
+
* For example, for [[R-Card]]s we use [[UDI]]s (specifically [[Entity UDI]]s) to point to Higgins [[Context]]s and [[Entity|Entities]]. When a [[UDI]] is resolved, we need to know what type of Authentication Materials is needed for opening the Context it points to.
*# urn:higgins:authmethod:1.0:anonymous
+
 
*# urn:higgins:authmethod:1.0:infocard
+
The interface '''IAuthNMaterials''' defines the following string identifiers for common types of Authentication Materials:
*# urn:higgins:authmethod:1.0:samlpolicy
+
<pre>
*# ... TODO ...
+
urn:udi:authnmaterials:1.0:anonymous
* Introduce an interface "IAuthnMaterials" in org.eclipse.higgins.idas.api.
+
urn:udi:authnmaterials:1.0:leastPrivileged
** Make this only a marker interface without methods
+
urn:udi:authnmaterials:1.0:implied
** As a convention, implementations of this interface should
+
urn:udi:authnmaterials:1.0:usernamePassword
 +
urn:udi:authnmaterials:1.0:namePrivatekey
 +
urn:udi:authnmaterials:1.0:p-infocard
 +
urn:udi:authnmaterials:1.0:m-infocard
 +
urn:udi:authnmaterials:1.0:samlpolicy
 +
</pre>
 +
 
 +
Notes:
 +
* The above identifiers can have a query string for passing additional information (e.g. constraints on the accepted Authentication Materials).
 +
* For example, in the case of '''urn:udi:authnmaterials:1.0:m-infocard''' this additional information could be a base64 encoded I-Card <object> element:
 +
<pre>
 +
urn:udi:authnmaterials:1.0:m-infocard?encoded-object-element
 +
</pre>
 +
* The special identifier '''urn:udi:authnmaterials:1.0:implied''' means that ''the party trying to open the Context must somehow know by itself what Authentication Materials to use''. E.g. in SSO scenarios, that party may already have a session established with the user, or in some other way know their credentials.
  
 
[[Category:Context Data Model 1.1]]
 
[[Category:Context Data Model 1.1]]

Latest revision as of 07:46, 14 July 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

This page describes the concept of Authentication Materials used in the Context Data Model 1.1. Authentication Materials are needed to open a Context. For example, in the case of opening an LDAP Context, a username and password may be required.

Authentication Materials are classes which implement the IdAS IAuthNMaterials interface. This is only a marker interface without methods.

Authentication Material Types

In certain situations, it is helpful to have identifiers for common types of Authentication Materials:

  • For example, for R-Cards we use UDIs (specifically Entity UDIs) to point to Higgins Contexts and Entities. When a UDI is resolved, we need to know what type of Authentication Materials is needed for opening the Context it points to.

The interface IAuthNMaterials defines the following string identifiers for common types of Authentication Materials:

urn:udi:authnmaterials:1.0:anonymous
urn:udi:authnmaterials:1.0:leastPrivileged
urn:udi:authnmaterials:1.0:implied
urn:udi:authnmaterials:1.0:usernamePassword
urn:udi:authnmaterials:1.0:namePrivatekey
urn:udi:authnmaterials:1.0:p-infocard
urn:udi:authnmaterials:1.0:m-infocard
urn:udi:authnmaterials:1.0:samlpolicy

Notes:

  • The above identifiers can have a query string for passing additional information (e.g. constraints on the accepted Authentication Materials).
  • For example, in the case of urn:udi:authnmaterials:1.0:m-infocard this additional information could be a base64 encoded I-Card <object> element:
urn:udi:authnmaterials:1.0:m-infocard?encoded-object-element
  • The special identifier urn:udi:authnmaterials:1.0:implied means that the party trying to open the Context must somehow know by itself what Authentication Materials to use. E.g. in SSO scenarios, that party may already have a session established with the user, or in some other way know their credentials.

Back to the top