PicketLink STS to send XACML Authorization Decisions

[anil.saldhana]

In PicketLink, we have demonstrated the return of XACML Authorization Decisions along with the authentication details back as SAML Assertions from the Identity Provider as part of SAML Web Browser based SSO.

We need to extend this concept to the PicketLink STS which will return authz statements as part of the saml tokens, if configured.

Now the client talking to the STS requiring the authz decisions will typically be enforcements points (PEP) in applications.

• What needs to be thought out is how would the request look like?
• Maybe we need to enhance the WSTrustClient api a bit to request authorization decisions also.

[sguilhen]

I think we can use the Claims section of the WS-Trust request message. This section is used when you want the STS to include extra information in the security tokens and the syntax is free. So, for instance, one could add the following to request roles to be added:

<wst:Claims Dialect="...">
  <claim:Role xmlns:claim="..."/>
</wst:Claims>

Of course, we are assuming the STS knows the specified dialect and knows how to interpret the Claims content in order to obtain the roles from, say, an external repository.

Maybe we can insert XACML authorization requests as part of the Claims section and make the STS aware of this, so it can communicate with a PDP and create authorization statements that will be added to the assertion that is going to be generated as part of the WS-Trust request.

[anil.saldhana]

As one use case, the STS can send in authorization statements just based on the authentication request (as an added bonus). No need to ask for it. Remember it is software handlers that are talking to the STS. As long as a trust relationship exists between the client and the STS, there is no harm in just returning the access decision statements.

The more configurable, the better.

[sguilhen]

Yes, this can be a bonus, but the STS must still know what kind of access is being attempted in order to include an authorization decision in the assertion, doesn't it?

[anil.saldhana]

True.  But (Client1,Resources) tuple is possible.  We can always configure saying that this enforcement point (xyz IP) will always ask questions about these resources.  So without asking, we may send the access decisions for a particular identity back.

On the other hand, we can have clients ask access requests.

[sguilhen]

I see, this is a more general, configuration-based, approach to obtain the authz statements. We just have to think about the changes that will be needed in the STS configuration file. Question: will the STS act as a PDP or will it delegate the decisions to an external PDP (obviously this requires configuration of the PDP)?

[anil.saldhana]

STS should incorporate the PDP as a start.  In theory, the STS is more of a token server handling claims (auth stuff) and there is a separate access control service that deals with authorization. In practice, I would say the STS would do both.

[vivek_biswas]

Yes, I agree STS should also act as a PDP. As of now I am designing an architecture using PicketLink in which the Authorization Decision is evaluated by an external XACML engine. The XACML Authorization Decision is converted into SAML Authorization Decision Assertion and is sent back to the service provider as part of the WSTrust Validate Response. Since WS-Trust Validate request can send new token. In this case, the token happens to be a SAML Authorization Assertion

[anil.saldhana]

Some discussion with Marcus:

(09:43:46 AM) anil: marcus: basically either the STS sends the access decisions as part of the original saml token response   or the wstrust client explicitly asks for the access decision statements.
(09:43:56 AM) anil: marcus: for the latter case, we need methods on the wstrustclient