SAML2 for SOAP services

Google Cloud Apigee
1

I have SOAP-pass-through proxies in Edge and I want to implement SAML2 in Apigee for authentication. I store user credits in BaaS as Identity provider. So I want to generate security token in Edge on authentication and then check it when client sends requests to back-end servers. Backend servers know nothing about authentication happening on proxy.

So my question is, where should I start and are there examples of similar case?

2

Hi Kirill!

Yes, you can generate SAML tokens on Apigee Edge. And you can validate tokens as well. There are {Generate,Validate}SAMLAssertion policies in the product. Here is a good writeup describing the use of the policies in a use case similar to yours.

You specifically called out the use of SAML. You may also be interested in using a JWT to represent the assertion. And also, you may not need a federated token at all. In other words, rather than sending back a SAML2 assertion or a JWT Assertion, either of which is readable by any holder of the assertion, you could just send back an opaque token, and allow Apigee Edge to track the entitlements attached to the token, in an opaque manner.

Apigee Edge is an OAuth2 token dispensary, and the OAuthV2/GenerateAccessToken policy allows you to attach any arbitrary attribute to the token, in the token store. Attributes might be scopes, roles, permissions, group memberships, or whatever you might imagine.

You used the term “credits” - and I don’t know exactly what that means to you, but… If you are imagining allowing each client to perform a certain number of API requests per day, or week or month, then… you can do that with OAuthV2 tokens and the Apigee Edge Quota policy. Learn about that here.

3

“Credits” - I mean creds, credentials :slightly_smiling_face: But is it okay to use OAuth for SOAP? I mean that for OAuth it doesn’t matter what service architecture is used but for developers that use SOAP may be strange to get json token? Isn’t SAML specific for SOAP services?

4

Good questions.

The JWT is a “JSON Web Token”, but in encoded form, it looks like “eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdWQiOiJkaW5vIiwic3ViIjoiS2lyaWxsIiwibmJmIjoxNTA5MTMwODE5LCJnZW5lcmF0b3ItdG9vbCI6ImdlbmVyYXRlSnd0LnNoIDIwMTcxMDEwLTEyMjkiLCJpc3MiOiJkaW5vY2hpZXNhLm5ldCIsImV4cCI6MTUwOTE0NTIxOSwiaWF0IjoxNTA5MTMwODE5fQ.vxOeWLsR5E16j_mlVC5n9QgQaSugRrgqEplrZzKurgk”. In other words, just a string. There’s nothing that would prohibit a SOAP client from transmitting that either in a SOAP Header or in the Body.

There are also opaque oauth tokens, which are nothing more than random strings of characters. Those too, could be sent within a SOAP envelope.

The SAML standard uses XML, like SOAP, but SAML was not built specifically for SOAP.

According to the WS-Security specification, the wsse:Security header (wsse:Security) “is, by design, extensible to support many types of security information.” BinarySecurityToken is designed to carry any binary value. You could use ValueType to denote “JWT” or “OAuth2” etc.

As for whether it would be strange for a developer using SOAP to employ JWT or an OAuth2 access token… Maybe. I can imagine defining a SOAP operation to obtain a token, and then stipulating that subsequent SOAP requests must carry that token in the wsse:Security header, as a BinarySecurityToken. That doesn’t seem too complicated. There is even a token type registered at IANA: urn:ietf:params:oauth:token-type:jwt. The SOAP message would look like this:

<soap:Envelope
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
    <soap:Header>
        <wsse:Security soap:mustUnderstand="1" >
            <wsse:BinarySecurityToken
                ValueType="urn:ietf:params:oauth:token-type:jwt"
                EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">JWT-GOES-HERE</wsse:BinarySecurityToken>
        </wsse:Security>
    </soap:Header>
    <soap:Body>
      ....
    </soap:Body>
</soap:Envelope>

SOAP and WS-Security is kinda complicated because of the flexibility the standards offer. So many different options. Signatures, Encryption, partial encryption, payloads that are both signed and encrypted… Different key types, and so on. But as an user of SOAP, you don’t need to support ALL of that. If you are using SOAP, you can specify the kind of security you want. If you are content to rely on TLS security for crypto, then you don’t need the application- or message-level encryption that is specified in SOAP. And you can use the wsse:Security header just to carry a token. Simple. This may or may not meet your needs. I’m suggesting it as just one possibility.