This chapter covers SAMLAssertions
8.3 Conveying the findings of a security service: SAML
8.3.3 AttributeStatement: Asserting user attributes
As we mentioned, we need to assert various attributes about the user to reduce the burden of security information on the consumer. An endpoint can use such informa- tion to make access control decisions or simply customize its behavior. Listing 8.3 shows how an assertion can state attributes of a subject, in this case, the groups the user belongs to:
<Assertion ...> ... <AttributeStatement> <Subject> <NameIdentifier NameQualifier="manning.com" Format="...:SAML:1.1:nameid-format:emailAddress"> [email protected] </NameIdentifier> </Subject> <Attribute AttributeName="memberOf" AttributeNamespace="http://manning.com/saml/attrns"> <AttributeValue>authors</AttributeValue> <AttributeValue>soasecimpl</AttributeValue> </Attribute> </AttributeStatement> ... </Assertion>
In this sample, the assertion is stating that the subject, [email protected], is a mem- berOf two groups named authors and soasecimpl. An AttributeStatement can provide values for any number of a subject’s attributes. We have only showed one in this listing.
In addition to asserting a user’s identity and attributes, a security service may also have the responsibility of asserting which actions a user is allowed to carry out and which he isn’t. Next, let us see how SAML makes that possible.
Listing 8.3 A sample SAML assertion making an attribute statement
A statement about the attributes of a subject
Identity of the subject
Namespace qualified name of an attribute One or more values of the attribute
163
Conveying the findings of a security service: SAML
8.3.4 AuthorizationDecisionStatement: Asserting authorization decisions
The security service may convey the kind of access granted to the subject for various resources using AuthorizationDecisionStatements. Listing 8.4 shows an example.
<Assertion ...> ... <AuthorizationDecisionStatement Resource="http://manning.com/ebooks/soasecimpl/" Decision="Permit"> <Subject> <NameIdentifier NameQualifier="manning.com" Format="...:SAML:1.1:nameid-format:emailAddress"> [email protected] </NameIdentifier> </Subject> <Action Namespace="http://manning.com/saml/actionns"> Annotate </Action> ... </AuthorizationDecisionStatement> ... </Assertion>
The assertion in this example states that the user, [email protected]
D
, is permittedC
to AnnotateE
the resource identified by the URI, http://manning.com/ebo-oks/soasecimpl/
B
.An AuthorizationDecisionStatement can record the authorization Decision for more than one Action on a Resource. We have only showed one in this listing.
As you can see from these examples, SAML allows a security service to communicate its findings using three kinds of statements.
1 Authentication statements to indicate that the identity of the caller has been
verified by the security service.
2 Attribute statements to indicate the caller’s attributes, such as the list of
groups/roles the caller belongs to.
3 Authorization decision statements to indicate the actions the caller is allowed to
carry out on one or more resources.
At the start of this section, we explained how the decoupling of security logic into a separate security service necessitates a mechanism such as SAML to communicate the findings of the security service to the service endpoint and other nodes in the SOAP message path. There is one more repercussion of moving security logic out into a sep-
Listing 8.4 A sample SAML assertion making an authorization decision statement
Statement about an authorization
decision Identity of the access-controlled resource
B
The authorization decisionC
Identity of the subjectD
Action for which the decision is given
E
164 CHAPTER 8 Implementing security as a service
arate security service. All communication between the security service and the service endpoint now needs to be secured just like any other data on the wire. In other words, SAML assertions are as vulnerable to forgery, tampering, and replay attacks as any other data on the wire. Appendix D describes in detail various techniques you can use to secure a SAML assertion against these vulnerabilities.
There’s much more to SAML than what we covered here. An important aspect in the context of a security service is the SAML protocol that specifies an interface for explicitly invoking a security service. We will discuss it in section 8.5.2.
SAML answers a very important question for implementing security as a service: How does the security service communicate its findings (and do so securely) to the ser- vice endpoint? You now understand the answer to this question. Let us solidify that understanding by looking at the implementation for a sample security service that uses SAML. Once we do that, we will return to address other challenges in the implementa- tion of a shared security service:.
8.4
Example implementation using OpenSAML
In this chapter, we are discussing the idea of offering security as a service. So far, you have seen the different use cases for a security service and how the findings of a secu- rity service can be represented using SAML.
We are now in a position to implement one of the use cases identified in section 8.2. WS-Addressing, described in chapter 3, and SAML, described in the previous section, are all you need to implement use case 4. In this section, we will show you a sample implementation of this use case.
In the sample implementation shown here, we will create and parse WSAddressing– defined XML elements using W3C DOM/SAAJ APIs—just as we created and parsed, for example, UsernameToken in chapter 3. On the other hand, when it comes to creat- ing and parsing SAML-defined elements, we will use a higher-level API provided by OpenSAML, like we used the Apache XML Security library in chapters 6 and 7 to cre- ate and parse elements defined by the XML Encryption and XML Signature standards. Figure 8.8 shows the components involved in the example and the data exchanges between them. The source endpoint explicitly routes the request to a security service that authenticates requests based on WS-Security UsernameToken. If the authentication is successful, the security service adds its findings as SAML assertions and forwards the message to the destination endpoint that is identified by the WS-Addressing headers in the message. We will use the brokerage service you have seen in the examples through- out this book as the destination endpoint.
Even though this example will only illustrate a security service that authenticates usernames and passwords, you can easily extend it using the code shown in previous three chapters to use other authentication schemes, encryption, and signatures. Table 8.3 provides the instructions to set up and run the example.1
1 One or more known issues in Apache Axis 1.x prevent this example from running successfully. See appendix
165
Example implementation using OpenSAML
You should now see the execution of web service calls as captured by tcpmon. You will see two requests, one to /axis/services/proxy and one to /axis/ser- vices/example6. The first of these is the request from the client endpoint to the secu- rity service, and the second is the request forwarded by security service to the brokerage service.
We will walk through the code that implements the client-side, the security service, and the server side to help you see how all the components come together. Let’s tackle the client-side code first.