Relationship SAML assertion and requested claim was: [higgins-dev] V3 Agenda for Higgins developers call on Thursday,July 16 at Noon EDT
Axel.N...@telekom.de
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-d...@eclipse.org [mailto:higgins-d...@eclipse.org] 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
> higgi...@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgi...@eclipse.org
https://dev.eclipse.org/mailman/listinfo/higgins-dev
Paul Trevithick
John Bradley
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.N...@telekom.de> 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
> ">
> XmY=</saml:AttributeValue>
> </saml:Attribute>
>
John Bradley
There are well understood deficiencies in SAML 1.1.
The SAML community was surprised that MS chose SAML 1.1 for the
default infocard token as opposed to SAML 2.0.
On the other hand it was not there job to keep us from learning by
experience ether.
Attributes and many other things are much clearer in 2.0.
The workaround for SAML 1.1 that was found is to declare URI a single
namespace, that way attributes can be named with a URI rather than a
string as they are by default.
We are going to have other issues as well with RPs using LDAP and
expecting OID attributes etc.
I am OK with leaving the SAML 1.1 token the way it is. That will
accelerate the need for a SAML 2.0 token for serious apps.
That may be the better long term solution.
However many people are invested in deploying cards with SAML 1.1
tokens today or in the next month or so.
If we want to do something to refine the SAML 1.1 profile (or make
one) to increase interoperability with existing SAML systems now is
the time.
Three months now now will be too late.
John B.
> Only have a second to respond here. My two cents: The way SAML deals
> with namespaces is brain dead. John’s saying we have to conform for
> interop reasons, but ouch! The SAML folks consider “all URIs” to be
> a namespace!
>
> On 7/17/09 4:51 AM, "Axel.N...@telekom.de"
> <Axel.N...@telekom.de> 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
>> ">
>> XmY=</saml:AttributeValue>
>> </saml:Attribute>
>>
>> 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="">
>> pikuMdkgfoX/XmY=</saml:AttributeValue>
John Bradley
I should probably clarify one thing that may be confusing which was
why it was removed in SAML 2.0.
AttributeNamespace is not a XML namespace. Its meaning and relation
to AttributeName is undefined in SAML 1.1.
Trying to treat it like an XML namespace is something that a lot of
people have done, including us.
As it is undefined what SAML processors do with it is also undefined.
If someone can point to a spec someplace that says to add a / to
AttributeName and concatenate the Attribute name to get the Claim and
to use that as the Unique name for the attribute I would love to find
it.
I will give another example where this is a problem.
I have a university that wants to take infocards.
All of may backend is LDAP that uses the EDUPerson schema.
I know phone number as urn:oid:2.5.4.20.
I can make a card with urn:oid:2.5.4.20 as the claim but I can't
return it from a STS using the replace the last / theory.
If I can't use URN or any arbitrary type of URI as a claim then we
have other problems, and seriously need to rethink the claims
dictionary.
John B.
On 17-Jul-09, at 9:50 AM, Paul Trevithick wrote:
> with namespaces is brain dead. John’s saying we have to conform for
> interop reasons, but ouch! The SAML folks consider “all URIs” to be
> a namespace!
>
> On 7/17/09 4:51 AM, "Axel.N...@telekom.de"
> <Axel.N...@telekom.de> 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
>> ">
>> XmY=</saml:AttributeValue>
>> </saml:Attribute>
>>
>> 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="">
>> pikuMdkgfoX/XmY=</saml:AttributeValue>