Loading...
 
ESA > Join & Share > Forums > HMA Forum > Feedback on HMA User Management 1.0 (07-118r8) from con terra after implementation for EUMETSAT

HMA Forum

Help

Show posts:
Jump to forum:

Feedback on HMA User Management 1.0 (07-118r8) from con terra after implementation for EUMETSAT

I would like to summarize some points we found which are inconsistent and/or need to be clarified in the HMA UserManagement Spec V 1.0 (a few were already commented on by Pierre Denis):

1. (Annex "B").
There is a need for the wst:RequestSecurityToken/wsp:DelegateTo element in the RST xml schema. But this element was dropped in the ws-trust.xsd starting on page 62.

Further a simple string is not allowed for element wst:RequestSecurityToken/wsp:DelegateTo as in the following example:

< wst:DelegateTo >
spot-image
< wst:DelegateTo >

Reason: The element declaration's content type is 'element-only'.

Declaring the DelegateTo element content as type xs:string in the HMA XSD will impede interoperability with the common WS-Trust schema. The WS-Trust Spec. suggests to use a security token or wsse:SecurityTokenReference to specify the receiving identity.

2.
It is not clearly defined in the spec how an STS is able to detect if the RST is coming from a federating entity. We decided as follows: if the RST includes a wst:DelegateTo and if the identifier is that of the STS itself then it comes from a federating entity.
Example (sent to EUMETSAT):

< wst:DelegateTo >
eumetsat
< wst:DelegateTo >
(please note that this conforms only to the HMA XSD, not the official WS-Trust XSD - see above)

3.
As far as we understand it is necessary that the user ids have to be reconciled a priori between the organizations.

4.
Section 6.4.3.3 (07-118r8):

The header of this section is “STS with trusted IdP”.
A client does not send (in a RST) anything to the STS which relates to another (trusted) IdP. There is only a signature created by the Client with its private key (s. Figure 6). So the correct wording of the section header should be “STS with trusted Client”.

Pierre Denis The title “A with B” is not meant to entail that A talks to B or B talks to A. “STS with trusted IdP” is just a short name (or nickname) to designate the case where the STS does not itself authentication. It is opposed to the two other cases where STS is an IdP, as explained in the introduction of 6.4.3.
Of course you are right by saying that STS just sees trusted clients; it cannot verify what these clients do to authenticate users. But, despite the limited responsibility and scope of STS, the OGC 07-118 requires that the client use an IdP to authenticate users. It is more stringent than trusting the client, whatever it may do (or not do) before issuing its RST with signature. So, when the STS trusts a client C, it means also that it trusts the IdP used by C.

5.
Section 7.1.3 (Response)

In the text we found:

…The SAML Token is always encrypted with the Federating Entity public key i.e. in both use cases the client receives the same response:
the federated response message to the Federating Entity STS and coming from an external Idp.
The federated response message returned by the Federating Entity STS to a client.

I do not understand this. What I understand is:
1. that the token is encrypted with the Relying Parties public key (see Figure 6).
2. That it is signed with the STSs private key which is not necessarily that of the federating entity but may possibly: s. 6.4.3.1 - 6.4.3.3

Pierre Denis I am afraid that this paragraph is obsolete. Sorry for this fault ! It should be corrected.
What you write is right but, to be more general, it covers RSTR returned by STS for all 3 use cases (hence figures 4, 5 and 6).



Please note, that the current spec is without fixing the bugs not implementable without proprietary interpretations and would probably lead to not interoperable implementations.
The bugs should be fixed within a 1.1(?) Version.


Re: Feedback on HMA User Management 1.0 (07-118r8) from con terra after implementation for EUMETSAT

Thanks for your comments, Uwe. Please find my answers below...


> I would like to summarize some points we found which are inconsistent and/or need to be clarified in the HMA UserManagement Spec V 1.0 (a few were already commented on by Pierre Denis):
>
> 1. (Annex "B").
> There is a need for the wst:RequestSecurityToken/wsp:DelegateTo element in the RST xml schema. But this element was dropped in the ws-trust.xsd starting on page 62.
>
Pierre Denis OK. This should be corrected, depending of the analysis of usage of DelegateTo (see my answer below).


> Further a simple string is not allowed for element wst:RequestSecurityToken/wsp:DelegateTo as in the following example:
>
> < wst:DelegateTo >
> spot-image
> < wst:DelegateTo >
>
> Reason: The element declaration's content type is 'element-only'.
>

Pierre Denis Yes, you are right; it shall contains an element, not a text.

> Declaring the DelegateTo element content as type xs:string in the HMA XSD will impede interoperability with the common WS-Trust schema. The WS-Trust Spec. suggests to use a security token or wsse:SecurityTokenReference to specify the receiving identity.
>

Pierre Denis I am afraid that this is not so easy because our purpose is not to delegate a token but to delegate authentication. I re-read the section “9.3 Delegation and Forwarding Requirements” of WS-Trust 1.3 spec; it is not crystal clear but I think that I misused the DelegateTo element. The need in OGC-07-118 was to specify the identifier of an external trusted  IdP, from which the STS can retrieve the URL and forward the RST. AFAIK, This is not the purpose of DelegateTo element, which is meant to specify a security token. This problem has to be analyzed in depth.


> 2.
> It is not clearly defined in the spec how an STS is able to detect if the RST is coming from a federating entity. We decided as follows: if the RST includes a wst:DelegateTo and if the identifier is that of the STS itself then it comes from a federating entity.
> Example (sent to EUMETSAT):
>
> < wst:DelegateTo >
> eumetsat
> < wst:DelegateTo >
> (please note that this conforms only to the HMA XSD, not the official WS-Trust XSD - see above)
>

Pierre Denis First note: I assume here that there is no problem with current usage of DelegateTo in OGC-07-118 (see above); we discuss on the concepts.
The intent of DelegateTo element was to allow the STS to relay the RST to another STS. Your proposition is to use it has a trick by replacing the information “Do not delegate identification” (normally, no DelegateTo element) by “Delegate to myself” (as in your example), right ? The two situations could indeed serve to set  as flag but this is tricky and I don’t see what is really the need to know whether “RST is coming from a federating entity”. If the goal is to identify the relying party (in order to encrypt the token with a specific public key), then the wsp:AppliesTo element could be use.


> 3.
> As far as we understand it is necessary that the user ids have to be reconciled a priori between the organizations.
>

Pierre Denis I would not say exactly that. The user id shall be known by one STS only, whether accessed directly or not. What is to be reconciled for interroperability is the set of attributes to put in the SAML token, with their names and semantics; then we have a baseline for defining PEP rules. Of course, if it is agreed that user id itself shall be a SAML token attribute, then you are right. See example in annex D.



> 4.
> Section 6.4.3.3 (07-118r8):
>
> The header of this section is “STS with trusted IdP”.
> A client does not send (in a RST) anything to the STS which relates to another (trusted) IdP. There is only a signature created by the Client with its private key (s. Figure 6). So the correct wording of the section header should be “STS with trusted Client”.
>

Pierre Denis The title “A with B” is not meant to entail that A talks to B or B talks to A. “STS with trusted IdP” is just a short name (or nickname) to designate the case where the STS does not itself authentication. It is opposed to the two other cases where STS is an IdP, as explained in the introduction of 6.4.3.
Of course you are right by saying that STS just sees trusted clients; it cannot verify what these clients do to authenticate users. But, despite the limited responsibility and scope of STS, the OGC 07-118 requires that the client use an IdP to authenticate users. It is more stringent than trusting the client, whatever it may do (or not do) before issuing its RST with signature. So, when the STS trusts a client C, it means also that it trusts the IdP used by C.

>
> 5.
> Section 7.1.3 (Response)
>
> In the text we found:
> “
> …The SAML Token is always encrypted with the Federating Entity public key i.e. in both use cases the client receives the same response:
> the federated response message to the Federating Entity STS and coming from an external Idp.
> The federated response message returned by the Federating Entity STS to a client.
> “
>
> I do not understand this. What I understand is:
> 1. that the token is encrypted with the Relying Parties public key (see Figure 6).
> 2. That it is signed with the STSs private key which is not necessarily that of the federating entity but may possibly: s. 6.4.3.1 - 6.4.3.3
>

Pierre Denis I am afraid that this paragraph is obsolete. Sorry for this fault ! It should be corrected.
What you write is right but, to be more general, it covers RSTR returned by STS for all 3 use cases (hence figures 4, 5 and 6).

>
>
> Please note, that the current spec is without fixing the bugs not implementable without proprietary interpretations and would probably lead to not interoperable implementations.
> The bugs should be fixed within a 1.1(?) Version.

Pierre Denis I am sorry for the mistakes. Corrections are required, indeed. Some analysis/discussions are still needed but I think that the implementation problem is limited to "IdP delegation" issue, which is use case number 2. Do you agree?



Re: Feedback on HMA User Management 1.0 (07-118r8) from con terra after implementation for EUMETSAT

Thanks Uwe! This set of comments shall be discussed via WebEx at the HMA AWG of 15 February 2012. Pierre as author of the OGC document to provide responses.


Show posts:
Jump to forum: