Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ICF.WG.Schemas] Relationship SAML assertion and requested claim was: [higgins-dev] V3 Agenda for Higgins developers call on Thursday, July 16 at Noon EDT 
Axel,
In a simple system concatenating the AttrinuteName with the AttributeNamespace to get back to a claim may work reliably
I am not recommending changing p-cards at this point, or necessarily how p-card claims are expressed as SAML attributes.
We have not considered the SAML profile for m-cards to any extent. It seems that IdP are copying the SAML format fro the p-card STS and that may not be the best thing for interoperability. 

My main concern are the new claims that we are creating for m-cards.
Once we have more complicated RPs that want to process the SAML token as a SAML token and pass it between systems, say gatewaying information cards through SiteMinder or openSSO this becomes a problem.
I think we do need a single method to represent claims in SAML. I am sort of surprised this hasn't been dealt with in the past.
I am told that many existing SAML systems won't validate our tokens because of the way we are encoding attributes.
Shibboleth got around the problem early on by defining there own namespace for attributes that defined the attribute name as a URI.
The approach others are taking is to use the SAML 2.0 constraint as the namespace. Shibboleth and others recognize this.
Making the attribute name a URI and the namespace the SAML 2.0 constraint makes life easier for RP that takes both SAML 1 and 2 tokens.
If we keep going as we are each m-card claim will be in its own namespace. That will be difficult for many of the large RPs to deal with.
Some will say come back to us after you have SAML 2.0 tokens sorted out that way we won't have to deal with this.
We can profile SAML 1.1 and say we are going to encode all claims as the personal STS is doing for m-cards and SAML 1.1 tokens, That is better than saying nothing and creating inter-op problems when someone try's a different namespace encoding.
It is when we start interacting with systems that get SAML tokens from multiple sources this may bight us in the ass. 
I just don't want it surprising us.

If someone knows some other way to address this I am interested.

John B.


On 17-Jul-09, at 4:51 AM, <Axel.Nennker@xxxxxxxxxx> wrote:
It seems to me that the relationship between SAML assertion and requested claims is under-defined.
The original proposal from Microsoft seems to imply that if a RP requests e.g. 
	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
Then the IdP answers with
<saml:Attribute AttributeName="privatepersonalidentifier" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims "> <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/ XmY=</saml:AttributeValue> 
	</saml:Attribute>
The "natural" way for the RP to translate this back to the requested claims seems to be to concatenate the AttributeName and AttributeNamespace (inserting a '/'). Now that the RP has the "full" claim assembled it might use it as a key to find a string that is displayed to the user or it just knows where to display the claims' value on a webpage. Maybe the claim's value or presence is just used to authorize the user to access a resource. 

The above scheme is the current agreement between IdP and RP!
Why should we change this agreement and force all RPs to change their code?
Neither claim URI nor claim name are intended to be displayed to a user. This agreement is internal and unvisible to the user. Never change a running system. Although we might want to mention this mechanism somewhere here: 
http://wiki.informationcard.net/index.php/Claim_URI_Syntax or
http://wiki.informationcard.net/index.php/Claim_Catalog
I could agree to having the AttributeNamespace to be "" but I do not know whether this legal. <saml:Attribute AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier " 
		AttributeNamespace="">
<saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/XmY=</ saml:AttributeValue> 
	</saml:Attribute>
<saml:Attribute AttributeName="http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06 " AttributeNamespace=""> 
		<saml:AttributeValue>you bet it is</saml:AttributeValue>
	</saml:Attribute>
Maybe the ICF "RP best practice" document should mention this topic too. 

-Axel

-----Ursprüngliche Nachricht-----
Von: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx ] Im Auftrag von John Bradley 
Gesendet: Donnerstag, 16. Juli 2009 18:42
An: Higgins (Trust Framework) Project developer discussions
Betreff: Re: [higgins-dev] V3 Agenda for Higgins developers call on Thursday,July 16 at Noon EDT 

The issue has come up that when dealing with m-cards RPs that expect
standard SAML tokens are going to have a issue with the current m-card
practice of putting each attribute into its own name-space.

Shibboleth and others started using URI for the attributes and a
single namespace quite a while ago.

The SAML token from the Higgins STS currently produces:
<saml:Attribute AttributeName="privatepersonalidentifier"
AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims
">
      <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/
XmY=</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute AttributeName="2009-06" AttributeNamespace="http://schemas.informationcard.net/@ics/icam-assurance-level-1
">
      <saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>

A proposed better syntax.

<saml:Attribute AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier
" AttributeNamespace="urn:oasis:names:tc:SAML:2.0:attrname- format:uri"> 
     <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/
XmY=</saml:AttributeValue>
</saml:Attribute>
   <saml:Attribute AttributeName="http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06
" AttributeNamespace="urn:oasis:names:tc:SAML:2.0:attrname- format:uri"> 
     <saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>

There is a question about what to do with the existing p-card claims,
should they stay in a separate namespace.

John B.

On 16-Jul-09, at 11:33 AM, Paul Trevithick wrote:


LOGISTICS: Time: noon Eastern (1600 UTC) U.S. Dial-in:
1-866-362-7064 / 89-2048#

AGENDA

1) [Brian] HIGGINS 1.1M7 TRACKING

	* M7 is targeted for July 24: Go to [1], click on  "All 1.1M7
items" link
	* All items are now in bugzilla, currently 14 are open

2) [Paul] WEB&WIKI DOCUMENTATION

	* Updated the "diagram key" [7] to organizing solutions, services,
packages, components, projects and sub-components. [7]
	* Introduced the concept of Packages and "Higgins Packages" wiki
category (if you want a list of them)
	* Most diagrams have been updated. You can now drill down to get
successive levels of diagram detail on successive links.
	* See Selector Overview [2], CardSync Service [3], RPPS package
[4]...etc

3) [Paul] PERSONA DATA MODEL 1.1 [6]

	* I've started work on documenting a new model for run-time user
data. It is a concrete application of the Context Data Model 1.1 and
layers over it (see diagram below).
	* Within the RPPS Package [4] are components that persist data
objects on behalf of the user. These include I-Card Registry and
others (not counting temporary caches). These include user account
data, the users set of cards, and other data. Some components use
IdAS 1.1 Package to persist their data while others manage their own
local data stores "above" IdAS. The overall data model has never
been documented in one place and it didn't have a name. As of now we
are calling it the Persona Data Model 1.0 (PDM 1.0).
	* PDM 1.0 has evolved over the past few years as we've piled on
more and more requirements. At this point, we need to evolve it
still further, but before we do so, we'd like to document the new
model Persona Data Model 1.1 so that it can be peer reviewed, combed
through and made as self-consistent, simple and powerful as
possible. The new model will have more generality and be easier to
implement than what we have today. This page, when complete, will
document Persona Data Model 1.1.
	* I've repeated the picture on [6] here:

       <image.png>

4) [Elmar Eperiesi-Beck (Corisecio) & Jeesmon] HIGGINS SELECTOR
SWITCH UPDATES

	* HSS build issues, questions
	* Intended enhancement: invoking mobile phones
	* On windows: moving away from tcp sockets to DLL?

5) [Paul, Brian] AUTOMATED SOLUTION LEVEL BUILDS [8]

	* Discuss/review requirements

6) [JohnB] Information Card claims

	* SAML attributes  (SAML 1.1 vs. 2.0, etc.)

[1] http://wiki.eclipse.org/Higgins_1.1M7
[2} http://wiki.eclipse.org/Selector_Overview
[3] http://wiki.eclipse.org/CardSync_Service
[4] http://wiki.eclipse.org/RPPS_Package
[5] http://eclipse.org/higgins/solutions/my_downloads.php
[6] http://wiki.eclipse.org/Persona_Data_Model_1.1
[7] http://wiki.eclipse.org/Diagram_Key
[8] http://wiki.eclipse.org/Automated_Solution-Level_Builds


<ATT00001.c>_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ICF-WG-Schemas" group. 
To post to this group, send email to icf-wg-schemas@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to icf-wg-schemas+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/icf-wg-schemas?hl=en
-~----------~----~----~----~------~----~------~--~---

Back to the top