The key to security is thinking it through and start thinking about the security architecture right from the start of the project. Since security is a crosscutting aspect, most parts of the security will be hard and costly to implement only at latter stages of the project.
You usually see on projects that SOA security is very coarse grained. Clients get access to all services or none. Using standard functionality it is easy to have both authentication and authorization per service method. The Oracle Web Service Manager has standard functionality to fine-tune the service access. The idea is to grant access to a service method based on a token. In this blog I will describe how to implement this on the Oracle Service Bus.
There are several ways to check the authentication and authorization of a client, i.e. by a username/password token or x509 certificates. In this tutorial we will give or deny access to a service based on the Common Name (CN) in a x509 certificate. Every service method will have access rules specifying which client can use the method. We will make use of an OWSM policy for configuration.
The following staps will have to be done:
- Configure keystore
- Configure IdentityAsserter to use x509
- Create OWSM policy
- Attach policy to OSB proxy service
- Configure OSB access rules
- User configuration
Generating a client certificate and exchanging public keys between OSB and client are necessary but will only be mentioned.
1. Configure OSB keystore
In the Enterprise Manager we need to configure the OWSM keystore. In the weblogic domain menu, go to the “Security/Security Provider Configuration”. Here we specify the keystore location. Keep in mind the owsm-keystore is a different store than the weblogic Identity- or TrustStore and found in a different location <DOMAINHOME>/config/fmwconfig.
Here we also configure the identity certificates used to sign or encrypt messages. Even though we don’t use neither signing nor encryption, we need to specify them. In this tutorial we use the same certificate everywhere.
2. Configure IdentityAsserter for x509
The weblogic server needs to be configured to use certificates when doing the authorization. To enable the x509, we need to log in to the weblogic console and navigate to the “security realm/myrealm/providers” tab.
Go into the DefaultIdentityAsserter.
Under the Active Types make sure the x509 is in the chosen column. If it is not there, move it there. Now open the Provider Specific tab.
Set the “User Name Mapper Attribute Type” to “CN”.
Now the server is enabled to use x509 certificates.
3. Create OWSM Policy
Now we need to set up a OWSM policy. In itself x509 tokens are part of the ws-security specification. Oracle build the OWSM around all the ws-* specs for the ease of (re)use.
In the Enterprise Manager , navigate back to the domain menu and chose “webservices/policies” from the drop down menu.
We adapt an existing x509 policy , to do that we look for 509 policies by typing “x509” in the name box and pressing the arrow behind it.
We will edit the “oracle/wss10_x509_token_with_message_protection_service_policy” by selecting it and pressing “create like”. This will create a copy of the policy and open it for editing.
Name it “oracle/wss10_x509_token_service _policy”.
On the request tab, deselect the “include entire body” underneath the “Message Signing Settings” and the “Message Encryption Settings”. Repeat that for the Response tab.
Now save the policy.
It is now easy to generate a client policy for this new policy . We repeat the same process but now on the “oracle/wss10_x509_token_with_message_protection_client_policy”. To find it we need to make sure that the “applies to” field is set to “service clients”.
Select the “oracle/wss10_x509_token_with_message_protection_client_policy” and chose “create like. Name it “oracle/wss10_x509_token_client _policy”. On the request tab, deselect the “include entire body” underneath the “Message Signing Settings” and the “Message Encryption Settings”. Repeat that for the Response tab. And save.
Now we are ready to start adding policies to an OSB proxy service.
4. Attach policy to OSB proxy service
We are going to secure the HelloWorld application on the OSB with the just created policy. In the SBConsole navigate to the HelloWorld proxy service in the HelloWorld project. In the “policies” tab, select the “from OWSM Policy store” radio button and click the “add” button.
Select the previously created policy:
Chose to update.
5. Configure OSB access rules
Open the security tab. Here we will configure the Message Access Security configuration.
Click on the “hello” operation link under the PS_HelloWorld next to Message Access Control. By clicking this link we configure the access control only for this operation in the service. We can also configure the access for the whole service by clicking the PS_HelloWorld link. The configuration in both cases is done exactly the same way.
Click “add conditions”.
In the predicate list chose user. This user will be the CN name of the x509 certificate of the client. The CN name needs to be added to the user list in the OSB configuration. It would make sense to use a Group here instead of a user. In a situation where you would have more clients calling this service, this would mean adding the new user (CN) to a group. This would be easier than adding new users to the service method access list.
Type the CN name and press the “add” button followed by “finish”.
Save the new configuration and commit the edit session.
6) User configuration
The final step is to add the user (CN) to the user list. In the SBConsole go to the Security Configuration to add a user by clicking the “add user” button.
In the add the CN name (client in this tutorial) as the user name. A password is required to add a user, but the password is not used in th x509 authorization. Save the new user.
7) Testing the security
Now we are ready to test the security. Unfortunately we cannot use SoapUI to test this security since SoapUI has a know bug around the usage of x509 tokens. SOAPSonar is capable of this test but security features are only available in the paid licenses. So we can create a web service proxy in Java or create a test service in another OSB instance.
When we send the following message:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsu:Timestamp wsu:Id="Timestamp-vprs64r5JnEgvZxZDpBRTg22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2016-06-06T20:38:24Z</wsu:Created>
<wsu:Expires>2016-06-06T20:43:24Z</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="BST-L3IG2qjmq8GONRHC1uoQpQ22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
MIIDVTCCAj2gAwIBAgIEa7Ms6zANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJOTDELMAkGA1UECBMCTkgxEjAQBgNVBAcTCUFtc3RlcmRhbTEMMAoGA1UEChMDY2FwMQwwCgYDVQQLEwNjYXAxDzANBgNVBAMTBnNlcnZlcjAeFw0xNjA2MDUxOTE3MzNaFw0xNzA1MzExOTE3MzNaMFsxCzAJBgNVBAYTAk5MMQswCQYDVQQIEwJOSDESMBAGA1UEBxMJQW1zdGVyZGFtMQwwCgYDVQQKEwNjYXAxDDAKBgNVBAsTA2NhcDEPMA0GA1UEAxMGc2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiv4F+IdoEhx9vCtzaZbhqRFHZ0DJ0t7yC5ciLKUfUGg0KLpM7eu/G4C+EgjW3Km1YgTxySSq7VTzfGAKkc3Zy3JSRhqWxdqcSASBkHw1P9sKoneub161n5AvQtMg3gnhqSmR5DDtQL1gGIaI9OcDPoAjawnXHTlXNh6PViE7Y+kn4l+2aGDtB6011bgnq4cy92g7qU3pYlPvXqprol93gc71rR3GBcLo68NVYmGXUV0fE4k40pbTU6WgPWNvj2GXJ6I1h8a8aLhCf3hiZxvHLwO+NLi5KyMlxkDNTYlfFMjWqY7H58zS6LF32oqeuGVGkhLwpJ4KY5qquq7djL0XcQIDAQABoyEwHzAdBgNVHQ4EFgQUdbuQdemGwR0W/hJx00qzzt8xo/AwDQYJKoZIhvcNAQELBQADggEBACMy2rSVtamGw+E7n85wk6mddu9HZUvflnxirqDkwIdRvgH99vjpCMHP/KezmtaMEBMttXEf6cl83gFTvIvHKNgG74Qj3o8yY3nPr6HE9XxYyEwDb0I1KS9AQWdfqsgHQZHiphdh6GGYiVbTFCirKm4YXIByA0QtG6mtpCg21SK0WxdpjudafiA6+Q1TciVj3DBt6gaVzCqPr0GkK/xnwVbQYK2t4/qGT+iq/ZgcgWebUusBP0XX+3HYBtoyYKsTcDsxy0IbFgQvXlTVy/45hYqj3zXC8hdY2wiqIMvbVBQ2XZwE+gwj+q3rU+DI+vaWFiQMZEZpGEJvRK2hYnCWybY=
</wsse:BinarySecurityToken>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#BST-L3IG2qjmq8GONRHC1uoQpQ22">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>qcZ/EnW9iZzk4n8E4/wiuI9cuts=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#Timestamp-vprs64r5JnEgvZxZDpBRTg22">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>jYKOr+ylEKneUrHSlt7Ntkyw2b4=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
aLhfEC4r4/CdYD3XTe8xEQn1J40gmB6KKxBtuu4XvsIFgDjbt6xgGIJG5A+AsefakDXz/lFRT1c628eomEsP/TOw/EPZRFi6Zkc38rCQV6nhSc5tyf4mRQ0Ac5FT0TPtUBnoX1Gl/8pN160GCqYwW7IJZUzUs3BvfS8qiFpKD/DLfU462jQJDvPFYBnw2fFyTtSBaOS2nNgO1JfFhuhVsIEI3aVnqrVPQ781zmcE+OKoF6iHzEUlEk4sMosYbFEYoe/gjX79+d1B6zzYCUs7PlCjZmFXaCehXur+TByNaeUCEgNJiFcA84IBxmcpcegco6wmppgVRS5erqBZNe9GtQ==
</dsig:SignatureValue>
<dsig:KeyInfo Id="KeyInfo-U1Ue0aPVWPgrEcxmeF5Iiw22">
<wsse:SecurityTokenReference>
<wsse:Reference URI="#BST-L3IG2qjmq8GONRHC1uoQpQ22" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
</wsse:Security>
</soap:Header>
<soapenv:Body>
<aw:hello xmlns:aw="http://aw.nl/">
<arg0>Alex</arg0>
</aw:hello>
</soapenv:Body>
|
We receive the following response:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsu:Timestamp wsu:Id="Timestamp-yDK4jnuwrHcSFsZctrbm1A22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsu:Created>2016-06-06T20:38:24Z</wsu:Created>
<wsu:Expires>2016-06-06T20:43:24Z</wsu:Expires>
</wsu:Timestamp>
<wsse:BinarySecurityToken ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" wsu:Id="BST-A1IiFjRIt5Qz0NG9ZqM9DQ22" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
MIIDVTCCAj2gAwIBAgIEa7Ms6zANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJOTDELMAkGA1UECBMCTkgxEjAQBgNVBAcTCUFtc3RlcmRhbTEMMAoGA1UEChMDY2FwMQwwCgYDVQQLEwNjYXAxDzANBgNVBAMTBnNlcnZlcjAeFw0xNjA2MDUxOTE3MzNaFw0xNzA1MzExOTE3MzNaMFsxCzAJBgNVBAYTAk5MMQswCQYDVQQIEwJOSDESMBAGA1UEBxMJQW1zdGVyZGFtMQwwCgYDVQQKEwNjYXAxDDAKBgNVBAsTA2NhcDEPMA0GA1UEAxMGc2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiv4F+IdoEhx9vCtzaZbhqRFHZ0DJ0t7yC5ciLKUfUGg0KLpM7eu/G4C+EgjW3Km1YgTxySSq7VTzfGAKkc3Zy3JSRhqWxdqcSASBkHw1P9sKoneub161n5AvQtMg3gnhqSmR5DDtQL1gGIaI9OcDPoAjawnXHTlXNh6PViE7Y+kn4l+2aGDtB6011bgnq4cy92g7qU3pYlPvXqprol93gc71rR3GBcLo68NVYmGXUV0fE4k40pbTU6WgPWNvj2GXJ6I1h8a8aLhCf3hiZxvHLwO+NLi5KyMlxkDNTYlfFMjWqY7H58zS6LF32oqeuGVGkhLwpJ4KY5qquq7djL0XcQIDAQABoyEwHzAdBgNVHQ4EFgQUdbuQdemGwR0W/hJx00qzzt8xo/AwDQYJKoZIhvcNAQELBQADggEBACMy2rSVtamGw+E7n85wk6mddu9HZUvflnxirqDkwIdRvgH99vjpCMHP/KezmtaMEBMttXEf6cl83gFTvIvHKNgG74Qj3o8yY3nPr6HE9XxYyEwDb0I1KS9AQWdfqsgHQZHiphdh6GGYiVbTFCirKm4YXIByA0QtG6mtpCg21SK0WxdpjudafiA6+Q1TciVj3DBt6gaVzCqPr0GkK/xnwVbQYK2t4/qGT+iq/ZgcgWebUusBP0XX+3HYBtoyYKsTcDsxy0IbFgQvXlTVy/45hYqj3zXC8hdY2wiqIMvbVBQ2XZwE+gwj+q3rU+DI+vaWFiQMZEZpGEJvRK2hYnCWybY=
</wsse:BinarySecurityToken>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI="#BST-A1IiFjRIt5Qz0NG9ZqM9DQ22">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>40CqPSxUPHjwg82/5w9OPU6aBFU=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#Timestamp-yDK4jnuwrHcSFsZctrbm1A22">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>DwAyt60T0b89M4SrgRywnJqYHLQ=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>
NQbToO8FYguXG+zc2m0BUnHdvIe8kdVfIJpgGRRjpdSu/Ujlog0e1AmGRxW8DEBdwkGuMIPQcAiRgFh/Nc83bdLWO/BpM2kQs/EHOHU4bOgyopgcBa1KskpibceDAgXl6OEWTB0yxZwE+l8fdnKCriOZzCLclh7xb0YjiMHUjT0GU68XrkGJ2RR+YSWSYK5rkauk9VcnxlMfxX2AOodVNsr46zMsLnAnRcd6cKUn5y9ByTmJ5e/lw8D92+xaUOXWK82g2AJ4dz3BjgytBFys8TLh6h8/cQdLawf8nobPLd+dKvHYhLLWrinQwH8zcvq00hEHpyINVEaG+JAMPGOLOA==
</dsig:SignatureValue>
<dsig:KeyInfo Id="KeyInfo-eH5r2CKJA2fRdnJVoPtZyg22">
<wsse:SecurityTokenReference>
<wsse:Reference URI="#BST-A1IiFjRIt5Qz0NG9ZqM9DQ22" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
</wsse:Security>
</soap:Header>
<soapenv:Body>
<helloResponse xmlns:aw="http://aw.nl/">
<return>OSB says : hello Alex</return>
</helloResponse>
</soapenv:Body>
</soapenv:Envelope>
|
|
The response indicates that the security criteria were met. To double check, remove the client from the OSB user list. We now get a security error, as expected:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>
BEA-386200: General web service security error
</faultstring>
<detail>
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-386200</con:errorCode>
<con:reason>General web service security error</con:reason>
<con:location>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
In the server log you will find the following :
javax.security.auth.login.LoginException: Cannot assert certificate. Reason oracle.security.jps.internal.api.jaas.AssertionException: javax.security.auth.login.FailedLoginException: [Security:090302]Authentication Failed: User server denied.
Conclusion
This is one way of granting access on a service method basis by the use of standard Oracle OSB and OWSM capabilities. With some thought the SOA landscape security can be easily fine tuned and thus optimizing the security of the SOA implementation. Even though the explained security can be easily added in later stage of the project, the key in security remains to start thinking about the security architecture from the beginning to make it an integral part of the architecture . Since security usually is a cross cutting aspect, it is usually very hard and costly to start implementing it at the later stages of the project.
