Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ICF.WG.Schemas] Re: Relationship SAML assertion and requested claim was: [higgins-dev] V3 Agenda for Higgins developers call on Thursday, July 16 at Noon EDT

Paul,

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:

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.Nennker@xxxxxxxxxx" <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