[security-services] RE: SAP Comments on SAML v1

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: [security-services] RE: SAP Comments on SAML v1

Dipak Chopra of SAP sent me some followup questions to the list he previously sent. I believe his questions and my answers may be of general interest, so he has given me permission to post them to the public lists.

> I appreciate such a detailed response from SSTC. I do
> understand that the last call process has ended and I also
> know committee's timelines to submit the spec to Oasis for
> consideration to become a standard.

As far as I am concerned, so far you have only heard my personal opionion, not the view of the TC. I plan a complete response to all external comments. However, you are right in thinking that in most cases there were no other responses than mine, so they are likely to be the TC's response as well.

> That is the reason I am sending this mail to you instead of
> posting it to comments area. I would say all of the
> issues/comments raised by us are addressed or answered except
> two of them.
>
> SAP-9 Issue: Core Document. Line # 829. With the current
> "Action" schema, we can't authorize a subject for a range. In
> other words, PDP can't set two related Action items. A
> specific implementation might interpret two actions as if
> they are related. For example, you need to authorize a
> subject for his "SpendingLimit" from $1000 to $2000. You
> can't do that? In SAP applications (as everywhere else!),
> supporting authorizations in some ranges, responsibilities is
> often required.
>
> TC Response: If you want to say a subject may spend up to a
> certain amount or a range of amounts, you should use an
> Attribute Statement. (although saying you can spend between
> $1000 and $2000, but not less than $1000 seems odd.) If you
> want an Authorization policy decision about a particular
> action, you should specify the exact action amount in
> question, e.g. $1234.56.
>
> My Response: I agree that I gave a weird example. Let me give
> you some real-life examples,
> - HR responsible persons divided up by employee surnames A-H,
> I-Q, R-Z.
> - accountants responsible for accounts 1-100, 101-200, 201-300 etc.
> - managers responsible for cost centers 1000-1005, 1006+1007,
> 1008-1020 etc.
> - controllers responsible for plants 1-3, 3-5, 6-8
>
> Based on your response, I will have to create multiple
> AttributeStatement. Let me take the first case, where a
> particular "Subject" is authorized to handle HR jobs for the
> employees for the range A-H and R-Z, it would look like this
> <AttributeStatement>
>     <Subject....../>
>     <Attribute AttributeName="FirstRangeLowerLimit"
> AttributeNamespace="...">
>         <AttributeValue>A</AttributeValue>
>     </Attribute>
>     <Attribute AttributeName="FirstRangeUpperLimit"
> AttributeNamespace="...">
>         <AttributeValue>H</AttributeValue>
>     </Attribute>
>     <Attribute AttributeName="SecondRangeLowerLimit"
> AttributeNamespace="...">
>         <AttributeValue>R</AttributeValue>
>     </Attribute>
>     <Attribute AttributeName="SecondRangeUpperLimit"
> AttributeNamespace="...">
>         <AttributeValue>Z</AttributeValue>
>     </Attribute>
> </AttributeStatement>

I think the simple solution is to use a multi-value attribute, which has two values which are understood to represent the range. I assume this is how it is done in X.509 Attribute Certificates.

> Here when the relying party gets the assertion with above
> AttributeStatement, it will have to interpret that the first
> two Attributes are related and third and fourth Attributes
> are related. In my opinion this is not an elegant solution.
> In comparison, if you look at the following fictitious
> AuthorizationDecisionStatement,
> <AuthorizationDecisionStatement>
>     <Subject....../>
>     <Actions>
>         <Action>
>             <LowerLimit>A</LowerLimit>
>             <UpperLimit>H</UpperLimit>
>         </Action>
>         <Action>
>             <LowerLimit>R</LowerLimit>
>             <UpperLimit>Z</UpperLimit>
>         </Action>
>     </Actions>
> </AuthorizationDecisionStatement>
>
> In the above statement, it is pretty clear to the relying
> party that there are two ranges of employees for which this
> subject has authorization. Nothing is left to the
> interpretation, which IMHO leads to interoperability. At the
> same time, if Action has to talk about a singleton
> ($1234.56), it can either make one value blank or same value
> in "LowerLimit" and "UpperLimit".

This is where you lost me. In the SAML model, users have attributes, which represent things they are potentially able to do.

However, in the context of an access request, that is the time a PDP has to make a decision, there is something in particular that the user wants to do.

To pick up on your examples,

- Change benefits for John Smith
- Record receivables for account 243
- Show budget actuals for cost center 1013

At this point there is no range, just a specific action.

A related point was debated at length last summer. The point was whether to permit wildcards in the resource. The TC view, which was a strong majority, but not unanimous, was that the only reason for a wildcard was to respond to multiple user requests without having to do multiple AuthZ decision requests to the PDP. In the view of the TC, this was in effect the distribution of authorization policy, not a policy decision.

Rather than support a kind of special, limited policy distribution mechanism, the TC defered this to XACML TC for a complete solution. Also the idea of sometimes having some policy in one place and other policy other places w/o a consistent scheme was unattractive. Finally, some people, like me are opposed to anything that encourages a PEP to cache decisions, because the policy model in our product (and many others) allows policies to be time-based and thus the answer may be different from one minute to the next.

> SAP-12 Issue: 12. Issue DS-4-11. Core Document. Line # 969.
> Why can't we take "RespondWith" zero statement resulting into
> a response with "StatusCode" as "Success"? This can be useful
> where client wants to test SAML Processor (without requesting
> any assertion information) if it accepts SAML requests or not.
>
> TC Response: This is a clever trick, but there are other ways
> to accomplish the same thing. The sense of the TC seems to be
> to prohibit zero statements.
>
> My Response: I understand the intent behind disallowing zero
> statements. To achieve this some other way, I can think about
> the scenario where a relying party sends a "Request" with
> "AssertionArtifact" with the value of artifact which is some
> random number. So server will return a "Response" with
> "StatusCode=Success" with zero assertions as there is no
> assertion for that artifact value. This is probably one of
> the ways to check if server accepts SAML requests or not.
> This is based on lines 979-981 in Core-27 document. Am I
> thinking in the right direction? Can you provide some other
> way of pinging server?

That is exactly the kind of thing I had in mind. Some other ideas:

Ask for Assertion ID 0

Ask for an inconstent combination of Request type and Respondwith (I am not 100% sure that this works as the semantics of Respondwith are under debate)

Ask a subject with a name identifier that can't match the syntax of your authority, I imagine an imbedded control character would do the trick

Use a mechanism in a lower protocol layer, e.g. ping

Hal