Broker trust relationships with WSO2 Identity Server
WS-Trust can be considered as an extension to WS-Security specification which primarily provides methods for managing security tokens and ways to broker the trust relationships. The web services trust model explained under the WS-trust specification defines three key participants.
Security token service (STS) is a web service that issues security tokens based on requesters needs. The consumer sends token requests to the STS as well as append tokens into the actual service request and submits them to the provider. The service provider makes the authentication decison on the service based on the token provided by STS. The service provider may also request token validations from the STS.
This post is not yet another detailed explanation about WS-trust and the associated frameworks. You can find many references just by googling the term, ws-trust. Instead, I'm going to take you through a set of step-by-step instructions on how WS-trust concepts can be used with WSO2 SOA middleware. Hope this post will be a starting point for your journey towards learning WS-trust.
SupportingTokens are used to provide additional claims for a requester (client). We will use SupportingToken policy assertion to describe claims which should be given by a consumer to access this particular web service.
The sp:IssuedToken element defines that the requester must talk to an STS to obtain the token.
The sp:IncludeToken attribute value is defined as ../AlwaysToRecipient, which says the token must be included as part of all messages sent from the initiator (service consumer) to the recipient.
The Address attribute of sp:Issuer element defines the token issuer whom the consumer must be contacted to get the security token. In other words, the endpoint address of the Security Token Service. In our case, it must be the STS url of IS.
[Note: I'm running WSO2 IS with port-offset 1, hence the https port is 9444]
The sp:RequestSecurityTokenTemplate element specifies the structure/type of the token which has to be issued by the STS. Later, you will observe the children of this element will be included as the part of RequestSecurityToken (RST) message which will be sent to the STS by consumer.
The t:TokenType element represents the type of the token such as UserNameToken, SAML-1.1, SAML-2.0. In our example, we ask STS To generate SAML-2.0 token by specifying SAML-2.0 token type URL.
t:KeyType represents the type of the key desired in security token, can be either public key, symmetric key or bearer. We will ask STS to generate the relatively simple key, bearer token. Bearer token does not require a proof of possession hence it is quite easy to dealt with.
t:Claims element defines the claims that must be included in the security token. We will request First Name and email address claims from the consumer.
You may raise the question why the First Name claim has been mapped to "http://wso2.org/claims/givenname" URI. We will be able to clear ourselves once we configure the token provider in the next step.
OK, now we understood all elements of the SupportingToken assertion of our custom web service policy. Let's upload the policy to embedded registry in WSO2 Application Service.
Locate /_system/config collection in registry browser and click on Add Resource.
Then, browse the axis2service.policy.xml which you have downloaded from the above location and click on Add.
Now, we have our custom policy in WSO2 Application Server. We can associate the policy to Axis2Service.
Click on Unsecured link in Axis2Service in Deployed Services page. You will be directed to Security for the service page. Find Policy From Registry section which is at the bottom of the page. Click on Configuration Registry icon and select the axis2service.policy.xml from /_system/config collection.
Click on next to proceed with the wizard. You will be at the Activate Security page where you can specify a trusted key store for the web service.
We will select wso2carbon.jks as the trusted key store. We have already discussed that STS is responsible for issuing tokens. Therefore, the STS is trusted by both consumer as well as the service provider. In order to do so, the public key certificate of STS should be imported to the trusted key store defined here. We will not explicitly do key exchanges in this example because we are using the same wso2carbon.jks keystore in both WSO2 Application Server and WSO2 Identity Server.
Now, we have our web service secured with a claim-aware security policy. Let's move in to the STS configurations.
First, we should secure the STS. There are multiple ways to authenticate to the Secure Token Service. The consumer can just present his username and password as UserNameTokens or X509 certificates to the STS. In this example, we will configure the STS using UserNameToken Authentication policy so that the clients should talk to STS by presenting their credentials.
Click on Apply Security Policy in the above screen. Select UsernameToken from the list of default security policies in the Security for the service page. Click on Next.
Now, we need to select a user group to which the service consumer belongs. We will incorporate our consumer into the admin group and request tokens from STS by presenting the default admin user credentials. Therefore, select admin as the user group and click on finish.
Next, we need to configure STS to add Axis2Service as a trusted service. In the above screen, enter the http endpoint url of the Axis2Service.
Endpoint Address = http://localhost:9765/services/Axis2Service/
Usually, the security token is signed by STS. Thus, we need to select a certificate alias to sign the token. We will select the default wso2carbon certificate alias.
Now, let's look at the user profile of admin user who is going to authenticate to the STS. Click on My Profiles at the left menu. Update Profile form will be displayed where you can enter various user attributes such as First Name, Last Name etc.
Make sure to add some values to First Name and Email address fields since we are going to use those as the required claims.
Click on Configure in the left menu and select Claim Management. You will find a set of claim dialects associated with the internal user store in IS. Click on the default claim dialect, http://wso2.org/claims. Click on First Name claim mapping.
As you can see in the following screen shot, First Name is mapped to givenName attribute.
Now, you should be able to understand why we have specified http://wso2.org/claims/givenName as the claimuri for First Name attribute in the service policy.
Now, all what left is to work on the service consumer. Basically, we need to generate the RequestSecurityToken programatically using a client, insert into the web service request and send to Axis2Service.
The wst:RequestSecurityToken element is used to request a security token from STS.
You would like to compare this with the SupportingToken policy assertion which we defined in step 1. In this, we will request a SAML2 token from STS (see wst:TokenType element) and indicate that the keytype is bearer. We also define the two claims we would present to the web service, givenname and emailaddress.
You can include RequestSecurityToken element into a SOAP message body and send to STS. You can use soapUI SOAP request editor as shown below.
Since we are using usernametoken authentication when submitting token request to STS, specify username and password under "Aut" tab in soapUI. Also specify WSS-passwordType as plaintext and WSS timeto live to some integer value. You can find more information about securing requests with username token with soapUI in one of my blog posts. Also, make sure to enable WS-Addressing for the token request as explained in another blog post of mine.
With all these, when you submit the request to STS endpoint (in our case, https://localhost:9444/services/wso2carbon-sts), you will get a response with the generated token (RequestSecurityTokenResponse). You will notice it in the response view of the above screen shot.
Now, you can extract the saml2:Assertion element from the response and embed it with the actual web service request message. For that, you can try adding SAML WSS entry for soapUI request and copy the extracted saml2:Assertion element into the Enter SAML Assertion text area as shown in the following screen shot. However, I was unsuccessful sending a message with bearer confirmation method with soapUI-4.5.2. It seems soapUI still supports sender vouches confirmation method only.
Because of this limitation, we need to follow a programmatic approach to insert the token into the web service request and forward to Axis2Service.
You can find the complete working client in this sourceforge account
Steps to run the client
1. Check out the complete source from https://sourceforge.net/p/charithablogsam/code/ci/master/tree/ and import the source into your IDE
2. Go to IS_HOME/bin and type ant. This will copy the necessary client libraries in to IS_HOME/repository/lib directory
3. Add IS_HOME/repository/lib directory to your IDE class path
4. Also add IS_HOME/repository/components/lib/bcprov-jdk15-132.jar to the class path
5. Modify Axis2ServiceClient according to the file paths in your system wherever necessary.
e.g:-
Policy stsPolicy = loadSTSPolicy("/resources/policies/sts.ut.policy.xml");
6. Run the client
You should see the output similar to the following.
Comment on or contact me directly at uoccharitha@gmail.com if this does not work for you!
- Security token service
- Service Consumer
- Service provider (Relying party)
Security token service (STS) is a web service that issues security tokens based on requesters needs. The consumer sends token requests to the STS as well as append tokens into the actual service request and submits them to the provider. The service provider makes the authentication decison on the service based on the token provided by STS. The service provider may also request token validations from the STS.
This post is not yet another detailed explanation about WS-trust and the associated frameworks. You can find many references just by googling the term, ws-trust. Instead, I'm going to take you through a set of step-by-step instructions on how WS-trust concepts can be used with WSO2 SOA middleware. Hope this post will be a starting point for your journey towards learning WS-trust.
Use Case
We are going to work on the basic trust establishment use case in the context of WS-trust specifiction. A SOAP web service consumer requests security token from a STS. We will make use of WSO2 Identity Server as the token provider. WSO2 Identity Server includes a Security Token Service (STS) which is capable of generating security tokens to build trust relationships.
Once the consumer possesses the necesary security tokens, he presents those tokens to authenticate to a web service deployed in WSO2 Application Server.
Pre-requisites:
1. Download and install WSO2 Identity Server 4.1.0 or later version
2. Download and install WSO2 Application Server 5.0.1 or later version
3. Any Java IDE (Eclipse, Idea)
4. soapUI (optional)
First, we need to figure out how we can start the end-to-end process. Obviously, the consumer initiates the process. But, how does the consumer know that he first needs to talk to a STS in order to consume the web service which is deployed in WSO2 application server?
The service provider needs to advertise those requirements through a WS-Policy. So, the starting point of our use case is to configure a policy in the web service.
Then, we need to look into the token provider, WSO2 Identity Server. As I have explained before, WSO2 IS comes with a Security Token Service. We need to configure it to issue tokens to the provider web service and secure STS using a WS-Security policy because the consumers should authenticate themselves to the STS when requesting tokens.
Finally, we will write a client/consumer (or just use a service invocation tool such as soapUI) to request a security token from STS and append it to the actual web service request message to authenticate to the web service which is deployed in WSO2 Application Server.
Step 1
Start WSO2 Application Server and log in to the management console as default admin user. Go to Manage --> Services --> Add --> AAR Service and deploy Axis2Service.aar which can be downloaded from here.
Once the service is deployed, we need to associate a security policy for our service. You will find a set of default web service security policies in security configuration wizard. However, we cannot use any of them for our use case. Why?
Our web service should be associated with a trust based security policy. A Security token which is offered by STS represents a set of claims. A claim defines a specific information about a particular user. For example, firstname or email address of the user.
In our example, Axis2Service (the web service deployed in service provider, wso2 application server) needs to be made as a claim-aware web service. So that, the users who are going to consume the service should present the claims defined in WS-Security policy.
Thus, we need to secure Axis2Service using a custom policy. You can download the complete policy from here. You might specially be interested in looking into the following element in the custom security policy.
<sp:SupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:IssuedToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<sp:Issuer>
<Address xmlns="http://www.w3.org/2005/08/addressing">https://localhost:9444/services/wso2carbon-sts</Address>
</sp:Issuer>
<sp:RequestSecurityTokenTemplate>
<t:TokenType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">urn:oasis:names:tc:SAML:2.0:assertion</t:TokenType>
<t:KeyType xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">http://schemas.xmlsoap.org/ws/2005/02/trust/Bearer</t:KeyType>
<t:KeySize xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">256</t:KeySize>
<t:Claims Dialect="http://wso2.org/claims"
xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust"
xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
<ic:ClaimType Uri="http://wso2.org/claims/givenname"/>
<ic:ClaimType Uri="http://wso2.org/claims/emailaddress"/>
</t:Claims>
</sp:RequestSecurityTokenTemplate>
<wsp:Policy>
<sp:RequireInternalReference/>
</wsp:Policy>
</sp:IssuedToken>
</wsp:Policy>
</sp:SupportingTokens>
SupportingTokens are used to provide additional claims for a requester (client). We will use SupportingToken policy assertion to describe claims which should be given by a consumer to access this particular web service.
The sp:IssuedToken element defines that the requester must talk to an STS to obtain the token.
The sp:IncludeToken attribute value is defined as ../AlwaysToRecipient, which says the token must be included as part of all messages sent from the initiator (service consumer) to the recipient.
The Address attribute of sp:Issuer element defines the token issuer whom the consumer must be contacted to get the security token. In other words, the endpoint address of the Security Token Service. In our case, it must be the STS url of IS.
[Note: I'm running WSO2 IS with port-offset 1, hence the https port is 9444]
The sp:RequestSecurityTokenTemplate element specifies the structure/type of the token which has to be issued by the STS. Later, you will observe the children of this element will be included as the part of RequestSecurityToken (RST) message which will be sent to the STS by consumer.
The t:TokenType element represents the type of the token such as UserNameToken, SAML-1.1, SAML-2.0. In our example, we ask STS To generate SAML-2.0 token by specifying SAML-2.0 token type URL.
t:KeyType represents the type of the key desired in security token, can be either public key, symmetric key or bearer. We will ask STS to generate the relatively simple key, bearer token. Bearer token does not require a proof of possession hence it is quite easy to dealt with.
t:Claims element defines the claims that must be included in the security token. We will request First Name and email address claims from the consumer.
You may raise the question why the First Name claim has been mapped to "http://wso2.org/claims/givenname" URI. We will be able to clear ourselves once we configure the token provider in the next step.
OK, now we understood all elements of the SupportingToken assertion of our custom web service policy. Let's upload the policy to embedded registry in WSO2 Application Service.
Locate /_system/config collection in registry browser and click on Add Resource.
Then, browse the axis2service.policy.xml which you have downloaded from the above location and click on Add.
Now, we have our custom policy in WSO2 Application Server. We can associate the policy to Axis2Service.
Click on Unsecured link in Axis2Service in Deployed Services page. You will be directed to Security for the service page. Find Policy From Registry section which is at the bottom of the page. Click on Configuration Registry icon and select the axis2service.policy.xml from /_system/config collection.
Click on next to proceed with the wizard. You will be at the Activate Security page where you can specify a trusted key store for the web service.
We will select wso2carbon.jks as the trusted key store. We have already discussed that STS is responsible for issuing tokens. Therefore, the STS is trusted by both consumer as well as the service provider. In order to do so, the public key certificate of STS should be imported to the trusted key store defined here. We will not explicitly do key exchanges in this example because we are using the same wso2carbon.jks keystore in both WSO2 Application Server and WSO2 Identity Server.
Now, we have our web service secured with a claim-aware security policy. Let's move in to the STS configurations.
Step 2
Start WSO2 Identity Server and log in to the management console using the default admin credentials. Select Secure Token Service from the left menu under the Manage section.
First, we should secure the STS. There are multiple ways to authenticate to the Secure Token Service. The consumer can just present his username and password as UserNameTokens or X509 certificates to the STS. In this example, we will configure the STS using UserNameToken Authentication policy so that the clients should talk to STS by presenting their credentials.
Click on Apply Security Policy in the above screen. Select UsernameToken from the list of default security policies in the Security for the service page. Click on Next.
Now, we need to select a user group to which the service consumer belongs. We will incorporate our consumer into the admin group and request tokens from STS by presenting the default admin user credentials. Therefore, select admin as the user group and click on finish.
Next, we need to configure STS to add Axis2Service as a trusted service. In the above screen, enter the http endpoint url of the Axis2Service.
Endpoint Address = http://localhost:9765/services/Axis2Service/
Usually, the security token is signed by STS. Thus, we need to select a certificate alias to sign the token. We will select the default wso2carbon certificate alias.
Now, let's look at the user profile of admin user who is going to authenticate to the STS. Click on My Profiles at the left menu. Update Profile form will be displayed where you can enter various user attributes such as First Name, Last Name etc.
Make sure to add some values to First Name and Email address fields since we are going to use those as the required claims.
Click on Configure in the left menu and select Claim Management. You will find a set of claim dialects associated with the internal user store in IS. Click on the default claim dialect, http://wso2.org/claims. Click on First Name claim mapping.
As you can see in the following screen shot, First Name is mapped to givenName attribute.
Now, you should be able to understand why we have specified http://wso2.org/claims/givenName as the claimuri for First Name attribute in the service policy.
Step 3
Now, all what left is to work on the service consumer. Basically, we need to generate the RequestSecurityToken programatically using a client, insert into the web service request and send to Axis2Service.
The wst:RequestSecurityToken element is used to request a security token from STS.
It will be a child of SOAP body. At the minumum level, the RequestSecurityToken element will be similar to the following.
<wst:RequestSecurityToken xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
<wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
</wst:TokenType>
<wst:KeyType>http://schemas.xmlsoap.org/ws/2005/02/trust/Bearer</wst:KeyType>
<wst:Claims xmlns:wsp="http://schemas.xmlsoap.org/ws/2005/02/trust"
wsp:Dialect="http://wso2.org">
<wsid:ClaimType xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity"
Uri="http://wso2.org/claims/givenname"/>
<wsid:ClaimType xmlns:wsid="http://schemas.xmlsoap.org/ws/2005/05/identity"
Uri="http://wso2.org/claims/emailaddress"/>
</wst:Claims>
</wst:RequestSecurityToken>
You would like to compare this with the SupportingToken policy assertion which we defined in step 1. In this, we will request a SAML2 token from STS (see wst:TokenType element) and indicate that the keytype is bearer. We also define the two claims we would present to the web service, givenname and emailaddress.
You can include RequestSecurityToken element into a SOAP message body and send to STS. You can use soapUI SOAP request editor as shown below.
Since we are using usernametoken authentication when submitting token request to STS, specify username and password under "Aut" tab in soapUI. Also specify WSS-passwordType as plaintext and WSS timeto live to some integer value. You can find more information about securing requests with username token with soapUI in one of my blog posts. Also, make sure to enable WS-Addressing for the token request as explained in another blog post of mine.
With all these, when you submit the request to STS endpoint (in our case, https://localhost:9444/services/wso2carbon-sts), you will get a response with the generated token (RequestSecurityTokenResponse). You will notice it in the response view of the above screen shot.
Now, you can extract the saml2:Assertion element from the response and embed it with the actual web service request message. For that, you can try adding SAML WSS entry for soapUI request and copy the extracted saml2:Assertion element into the Enter SAML Assertion text area as shown in the following screen shot. However, I was unsuccessful sending a message with bearer confirmation method with soapUI-4.5.2. It seems soapUI still supports sender vouches confirmation method only.
Because of this limitation, we need to follow a programmatic approach to insert the token into the web service request and forward to Axis2Service.
You can find the complete working client in this sourceforge account
Steps to run the client
1. Check out the complete source from https://sourceforge.net/p/charithablogsam/code/ci/master/tree/ and import the source into your IDE
2. Go to IS_HOME/bin and type ant. This will copy the necessary client libraries in to IS_HOME/repository/lib directory
3. Add IS_HOME/repository/lib directory to your IDE class path
4. Also add IS_HOME/repository/components/lib/bcprov-jdk15-132.jar to the class path
5. Modify Axis2ServiceClient according to the file paths in your system wherever necessary.
e.g:-
Policy stsPolicy = loadSTSPolicy("/resources/policies/sts.ut.policy.xml");
6. Run the client
You should see the output similar to the following.
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="urn:uuid:D6511FA799FD47AC4D1373081003469" IssueInstant="2013-07-06T03:23:23.465Z" Version="2.0"><saml2:Issuer>localhost</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod>
<ds:Reference URI="#urn:uuid:D6511FA799FD47AC4D1373081003469">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"></ec:InclusiveNamespaces></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod>
<ds:DigestValue>MO6PnDsz+lbXsvuFRmMBwa7r0j4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
i8S8BFxLJ59DpYUF8s8/Glt8x0n2plGPgCJKigB6eopRt7Y52LLnSqRimkWTWx57wdwjOFENMTPa
ZsYgBJ3AlxKRDQoy23OBOjrRA+S0WQ4Pq3EGcmM5XGKxU9pTNnh/xEhT4lDN9QE12Z1rttFz6RkU
AgFt3nmvqNqZvbNMga4=
</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICNTCCAZ6gAwIBAgIES343gjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJVUzELMAkGA1UE
CAwCQ0ExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxDTALBgNVBAoMBFdTTzIxEjAQBgNVBAMMCWxv
Y2FsaG9zdDAeFw0xMDAyMTkwNzAyMjZaFw0zNTAyMTMwNzAyMjZaMFUxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIDAJDQTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzENMAsGA1UECgwEV1NPMjESMBAGA1UE
AwwJbG9jYWxob3N0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCUp/oV1vWc8/TkQSiAvTou
sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
HpwvnH/DW8ZccGvk53I6Orq7hLCv1ZHtuOCokghz/ATrhyPq+QktMfXnRS4HrKGJTzxaCcU7OQID
AQABoxIwEDAOBgNVHQ8BAf8EBAMCBPAwDQYJKoZIhvcNAQEFBQADgYEAW5wPR7cr1LAdq+IrR44i
QlRG5ITCZXY9hI0PygLP2rHANh+PYfTmxbuOnykNGyhM6FjFLbW2uZHQTY1jMrPprjOrmyK5sjJR
O4d1DeGHT/YnIjs9JogRKv4XHECwLtIVdAbIdWHEtVZJyMSktcyysFcvuhPQK8Qc/E/Wq8uHSCo=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">admin</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2013-07-06T03:23:23.465Z" NotOnOrAfter="2013-07-06T03:28:23.465Z"></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2013-07-06T03:23:23.465Z"><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement><saml2:AttributeStatement><saml2:Attribute Name="http://wso2.org/claims/emailaddress" NameFormat="http://wso2.org/claims/emailaddress"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">charitha@wso2.com</saml2:AttributeValue></saml2:Attribute><saml2:Attribute Name="http://wso2.org/claims/givenname" NameFormat="http://wso2.org/claims/givenname"><saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">charitha</saml2:AttributeValue></saml2:Attribute></saml2:AttributeStatement></saml2:Assertion>
Response : <ns:echoStringResponse xmlns:ns="http://service.carbon.wso2.org"><ns:return>Hello world1</ns:return></ns:echoStringResponse>
Comment on or contact me directly at uoccharitha@gmail.com if this does not work for you!
Comments
Subash
Subash