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.
Difference between revisions of "Authentication Materials"
(→Proposal for Goal #1) |
|||
Line 24: | Line 24: | ||
*# '''urn:higgins:authmethod:1.0:implied''' | *# '''urn:higgins:authmethod:1.0:implied''' | ||
*# ... TODO ... | *# ... TODO ... | ||
− | * | + | * The above identifiers can have a query string for passing additional information (e.g. constraints on the accepted Authentication Materials) |
+ | ** In the case of '''urn:higgins:authmethod:1.0:m-infocard''' this additional information could be a base64 encoded I-Card <object> element. | ||
<pre> | <pre> | ||
urn:higgins:authmethod:1.0:m-infocard?policyhere | urn:higgins:authmethod:1.0:m-infocard?policyhere | ||
</pre> | </pre> | ||
− | * The special identifier '''urn:higgins:authmethod: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 | + | * The special identifier '''urn:higgins:authmethod: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. |
== Proposal for Goal #2 == | == Proposal for Goal #2 == |
Revision as of 12:00, 19 March 2009
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
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
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
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-Cards we use 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.
- (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 for Goal #1
- Define the following identifiers for common types of Authentication Materials:
- The above identifiers can have a query string for passing additional information (e.g. constraints on the accepted Authentication Materials)
- In the case of urn:higgins:authmethod:1.0:m-infocard this additional information could be a base64 encoded I-Card <object> element.
urn:higgins:authmethod:1.0:m-infocard?policyhere
- The special identifier urn:higgins:authmethod: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.
Proposal for Goal #2
- Introduce an interface "IAuthnMaterials" in org.eclipse.higgins.idas.api.
- Make this only a marker interface without methods
- As a convention, implementations of this interface should provide a toString() method that can serialize the Authentication Materials to a String, and a constructor with the arguments (IContext, String), which can be used to reconstruct the Authentication Materials from the String.