WSO2 APIM/IS: How to configure default identity provider - wso2

I have created a custom federated authenticator and configure it in an identity provider called 'kbank'.
How can I configure to have all Service Providers use this Identity Providers by default without having to individually specify it for each Service Providers. Since in API Manager, each application is created as Service Provider so there will be a lot and increasing Service Providers in our system.
In Service Provider configuration page I can see there is an option for "Default" but I don't how to specify the default.
Thank you very much.

You can specify the default authenticator or rather the default sequence using the application-authentication.xml found in IS_HOME/repository/conf/identity. You can change this using the <Sequences> section.
Here as shown below the default sequence is set as a single step authentication sequence using the BasicAuthenticator
<Sequences>
<!-- Default Sequence. This is mandatory -->
<Sequence appId="default">
<Step order="1">
<Authenticator name="BasicAuthenticator"/>
</Step>
</Sequence>
</Sequences>
You can modify it to use any authenticator as the default. You need to specify the name of the authenticator.

Thanks to this post, the solution for my problem is I have to modify <APIM_Home>\repository\conf\identity\service-providers\default.xml as follow
<ServiceProvider>
<ApplicationID>1</ApplicationID>
<ApplicationName>default</ApplicationName>
<Description>Default Service Provider</Description>
<InboundAuthenticationConfig>
<InboundAuthenticationRequestConfigs>
<InboundAuthenticationRequestConfig>
<InboundAuthKey>default</InboundAuthKey>
<InboundAuthType></InboundAuthType>
<Properties></Properties>
</InboundAuthenticationRequestConfig>
</InboundAuthenticationRequestConfigs>
</InboundAuthenticationConfig>
<LocalAndOutBoundAuthenticationConfig>
<AuthenticationSteps>
<AuthenticationStep>
<StepOrder>1</StepOrder>
<FederatedIdentityProviders>
<IdentityProvider>
<IdentityProviderName>kbank</IdentityProviderName>
<IsEnabled>true</IsEnabled>
<FederatedAuthenticatorConfigs>
<FederatedAuthenticatorConfig>
<Name>MyAuthenticator</Name>
<IsEnabled>true</IsEnabled>
</FederatedAuthenticatorConfig>
</FederatedAuthenticatorConfigs>
<DefaultAuthenticatorConfig>MyAuthenticator</DefaultAuthenticatorConfig>
<JustInTimeProvisioningConfig>
<UserStoreClaimUri></UserStoreClaimUri>
<ProvisioningUserStore>PRIMARY</ProvisioningUserStore>
<IsProvisioningEnabled>true</IsProvisioningEnabled>
</JustInTimeProvisioningConfig>
</IdentityProvider>
</FederatedIdentityProviders>
<SubjectStep>true</SubjectStep>
<AttributeStep>true</AttributeStep>
</AuthenticationStep>
</AuthenticationSteps>
</LocalAndOutBoundAuthenticationConfig>
<RequestPathAuthenticatorConfigs></RequestPathAuthenticatorConfigs>
<InboundProvisioningConfig></InboundProvisioningConfig>
<OutboundProvisioningConfig></OutboundProvisioningConfig>
<ClaimConfig>
<AlwaysSendMappedLocalSubjectId>true</AlwaysSendMappedLocalSubjectId>
</ClaimConfig>
<PermissionAndRoleConfig></PermissionAndRoleConfig>
</ServiceProvider>

Related

Issue importing service provider via file configuration WSO2 Identity Server

I am working to import a service provider into my WSO2 Identity Server using the "file configuration" feature. The file I am importing from has a claim called "Local Claim"
Configuration Screenshot
Configuration XML File
<?xml version="1.0" encoding="UTF-8"?><ServiceProvider>
<ApplicationName>Local Claim SP</ApplicationName>
<Description/>
<InboundAuthenticationConfig>
<InboundAuthenticationRequestConfigs>
<InboundAuthenticationRequestConfig>
<InboundAuthKey>Local Claim SP</InboundAuthKey>
<InboundAuthType>openid</InboundAuthType>
<InboundConfigType>standardAPP</InboundConfigType>
<Properties/>
</InboundAuthenticationRequestConfig>
<InboundAuthenticationRequestConfig>
<InboundAuthKey>Local Claim SP</InboundAuthKey>
<InboundAuthType>passivests</InboundAuthType>
<InboundConfigType>standardAPP</InboundConfigType>
<Properties/>
</InboundAuthenticationRequestConfig>
</InboundAuthenticationRequestConfigs>
</InboundAuthenticationConfig>
<LocalAndOutBoundAuthenticationConfig>
<AuthenticationSteps/>
<AuthenticationType>default</AuthenticationType>
<alwaysSendBackAuthenticatedListOfIdPs>false</alwaysSendBackAuthenticatedListOfIdPs>
<UseTenantDomainInUsername>false</UseTenantDomainInUsername>
<UseUserstoreDomainInRoles>true</UseUserstoreDomainInRoles>
<UseUserstoreDomainInUsername>false</UseUserstoreDomainInUsername>
<EnableAuthorization>false</EnableAuthorization>
</LocalAndOutBoundAuthenticationConfig>
<RequestPathAuthenticatorConfigs/>
<InboundProvisioningConfig>
<ProvisioningUserStore/>
<IsProvisioningEnabled>false</IsProvisioningEnabled>
<IsDumbModeEnabled>false</IsDumbModeEnabled>
</InboundProvisioningConfig>
<OutboundProvisioningConfig>
<ProvisioningIdentityProviders/>
</OutboundProvisioningConfig>
<ClaimConfig>
<RoleClaimURI/>
<LocalClaimDialect>false</LocalClaimDialect>
<IdpClaim/>
<ClaimMappings>
<ClaimMapping>
<LocalClaim>
<ClaimUri>http://wso2.org/claims/localClaim</ClaimUri>
<claimId>0</claimId>
</LocalClaim>
<RemoteClaim>
<ClaimUri>Local Claim</ClaimUri>
<claimId>0</claimId>
</RemoteClaim>
<RequestClaim>true</RequestClaim>
<MandatoryClaim>false</MandatoryClaim>
</ClaimMapping>
</ClaimMappings>
<AlwaysSendMappedLocalSubjectId>false</AlwaysSendMappedLocalSubjectId>
<SPClaimDialects/>
</ClaimConfig>
<PermissionAndRoleConfig>
<Permissions/>
<RoleMappings/>
<IdpRoles/>
</PermissionAndRoleConfig>
<IsSaaSApp>false</IsSaaSApp>
</ServiceProvider>
When I try to import the XML file, I get the following error:
I looked at my local claims on the Identity Server I am trying to import to and I have the local claim that the error is referencing.
That error message doesn't make sense to me. Am I misunderstanding what a local claim is? I thought adding a claim to the http://wso2.org/claims dialect is how you add a local claim. So why is it throwing an error about a claim that I have in the dialect?
Problem is you have not created the claim http://wso2.org/claims/localClaim in the Identity Server you are importing this SP into. So what you need to do is add the required local claim by navigating to Claims -> Add -> Add Local Claim
After doing this try to import the service provider again.

WSO2 Mobile Device Manager redirection to localhost

here is a brief explanation of my problem :
I am using WSO2 Mobile Device Manager on local-ip:9443/
When I try to go to the store and do authentification (local-ip:9443/store/) I am being automatically redirected to localhost:9443/authenticationendpoint/login.do
Where can I configure the redirection address?
FYI: I was using V1 of WSO2 EMM and I did the same thing by modifying the files below but now I am on V2 :
/modules/distribution/src/repository/conf/axis2/axis2.xml
/modules/distribution/src/repository/conf/api-manager.xml
/modules/distribution/src/repository/conf/carbon.xml
/modules/distribution/src/repository/conf/axis2/axis2.xml
/modules/distribution/src/repository/conf/sso-idp-config.xml
I found a solution !
To resolve this automatic redirection problem I had to make the modifications below :
\modules\distribution\target\wso2mdm-2.0.0\repository\conf\carbon.xml
...
<HostName>your_server_ip</HostName>
...
<MgtHostName>your_server_ip</MgtHostName>
...
\modules\distribution\target\wso2mdm-2.0.0\repository\conf\app-manager.xml
<SSOConfiguration>
<!-- URL of the IDP use for SSO -->
<IdentityProviderUrl>https://your_server_ip:9443/samlsso</IdentityProviderUrl>
<Configurators>
<Configurator>
<name>wso2is</name>
<version>5.0.0</version>
<providerClass>org.wso2.carbon.appmgt.impl.idp.sso.configurator.IS500SAMLSSOConfigurator</providerClass>
<parameters>
<providerURL>https://your_server_ip:9443</providerURL>
<username>admin</username>
<password>admin</password>
</parameters>
</Configurator>
</Configurators>
</SSOConfiguration>
\modules\distribution\target\wso2mdm-2.0.0\repository\conf\api-manager.xml
Whenever you find ${carbon.local.ip} change it by your_server_ip
\modules\distribution\target\wso2mdm-2.0.0\repository\conf\identity\sso-idp-config.xml
Change every localhost by your_server_ip
\modules\distribution\target\wso2mdm-2.0.0\repository\conf\identity\identity.xml
<ThriftHostName>your_server_ip/ThriftHostName>

Getting 403 Forbidden, trying to access secured web service

Has anyone successfully secured a web service using Active Directory credentials instead of an application specific username/password?
I have an application that talks to web services written with Axis2 1.5.1 and deployed on Tomcat 6.0.24, deployed on Linux, FWIW.
I have changed Tomcat from a JDBCRealm, authenticating against a database, to a JAASRealm, configured to access AD with Centrify (the client's preferred solution).
This works with web applications but for web services I get a 403 response.
I have tested using a simple Axis2 service (written with Axis2 1.5.1) and deployed against Tomcat 6.0.24 and 7.0.63. I've also tried with a web service written using Axis2 1.6.2. I get the same result in each case. I'm testing using a browser, BTW. When the service works I get xml; when it doesn't I get the error.
I'm wondering whether I need to change something in axis2.xml since even https://tomcat:8443/HelloWorld (my service is called HelloWorld) generates a 403.
Some configuration details...
I've changed the realm in server.xml to the following
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassName="com.centrify.dc.tomcat.RolesPrincipal"
userClassName="com.centrify.dc.tomcat.LoginPrincipal" />
<Valve className="com.centrify.dc.tomcat.ContextValve" />
In web.xml I have added
<security-constraint>
<display-name>Security Web Service</display-name>
<web-resource-collection>
<web-resource-name>Secured Area</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>USER</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>CENTRIFYDC</realm-name>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>USER</role-name>
</security-role>
I've mapped the USER role to one of my AD groups
Any suggestions or guidance or setups that have worked for someone would be very useful, thanks.
The 403 error is indicating the permission problem after authentication. It is because after SSO, the server will check for group membership to see if the user got proper permission. The 403 error is coming from the configuration part of role mapping. SSO to the server is actually working fine.
We would suggest you to try the following(the following example is using 5.5 version tomcat but it will be the same for later version):
Configure tomcat for Centrify
a. Configure tomcat for Centrify by using configure.pl:
cd /usr/share/centrifydc/java
./configure.pl
Enter /opt/apache-tomcat-5.5.25 when prompted for the tomcat directory.
Enter /usr/jdk1.5.0_15 when prompted for the java directory.
Enter y when prompted if you want to configure Tomcat for SSL
Enter n when prompted if you want to configure Tomcat for SSL communication with ADFS server
Take default for everything else.
Configure webdav for Centrify and use kerberos(SPNEGO) for authentication
a. Set the logon realm to CENTRIFYDC:
cd /opt/apache-tomcat-5.5.25/webapps/
mkdir webdav/META-INF
create webdav/META-INF/context.xml as:
<Context path="/webdav">
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassNames="com.centrify.dc.tomcat.RolesPrincipal"
userClassNames="com.centrify.dc.tomcat.LoginPrincipal"/>
<Valve className="com.centrify.dc.tomcat.ContextValve"/> </Context>
b. Configure mapping of AD groups to roles for the jspwiki app.
cp /usr/share/centrifydc/java/templates/centrifydc.xml webdev/WEB-INF/centrifydc.xml
modify RoleMapping section in webdev/WEB-INF/centrifydc.xml as follow:
<RoleMapping separator=";">
<Role name="user" group="*" user="*"/>
<Role name="#ROLE2#" group="#GROUP2#"/>
<Role name="#ROLE3#" user="#USER3#"/>
</RoleMapping>
c. Configure web.xml to use kerberos(SPNEGO) for authentication:
Edit web.xml and add
<login-config>
<auth-method>SPNEGO</auth-method>
<realm-name>Default</realm-name>
</login-config>
<!--
OPTIONAL: Add CentrifyFilter to set the authenticated user's attributes
such as group membership in HTTP headers. You must also configure the
<SetHeaders> element in centrifydc.xml to set user attributes in HTTP
headers.
This filter is not needed if you do not want the authenticated
user's attributes set in HTTP headers.
-->
<filter>
<filter-name>CentrifyFilter</filter-name>
<filter-class>com.centrify.dc.wbase.DCFilter</filter-class>
</filter>
<!--
OPTIONAL: Apply (map) CentrifyFilter to the url patterns in the
<security-constraint> section of this application to set the
authenticated user's attributes in HTTP headers.
This <filter-mapping> is not needed if you do not want the
authenticated user's attributes set in HTTP headers.
-->
<filter-mapping>
<filter-name>CentrifyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>ProtectedResource</web-resource-name>
<url-pattern>/index.html</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>user</role-name>
</auth-constraint>
</security-constraint>
<security-role>
<description>
An test role
</description>
<role-name>user</role-name>
</security-role>
You could also refer to the Centrify Java Guide p.135 for the example for role mapping configured as follow:
Extensible Markup Language (XML) files, like the centrifydc.xml file, are structured documents that contain a set of supported elements enclosed in opening and closing angle (< >) brackets. The elements can be required or optional depending on the requirements of the application. The following is an example of how the key elements defined in the centrifydc.xml file:
<Centrifydc>
<enableAuthSchemes>Negotiate,NTLM,Basic</enableAuthSchemes>
<adclientSocket>/var/centrifydc/daemon</adclientSocket>
<RoleMapping>
<Role name=”role1” group=”arcade.com/Users/Sales”/>
</RoleMapping>
</Centrifydc>
Although the template centrifydc.xml file contains some default settings, these default settings should be modified in the copy of the centrifydc.xml file you place in an application’s WEB-INF directory. The following table describes the elements you can set in the centrifydc.xml file.
If you need any further assistance, please feel free to contact Centrify Technical Support directly.
There were a couple of problems. The first was an error was in the server.xml file. JAASRealms can accept several classes for role and user so the properties are roleClassNames and userClassNames as follows
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="CENTRIFYDC"
roleClassNames="com.centrify.dc.tomcat.RolesPrincipal"
userClassNames="com.centrify.dc.tomcat.LoginPrincipal" />
The second issue is around using several applications which use different authorization. The centrifydc.xml file maps roles when the app is first authenticated. However, if org.apache.catalina.authenticator.SingleSignOn is enabled then the roles are set only for the application that performs the authentication. Thereafter, only the roles set in the authenticating application's centrifydc.xml file are set. Other applications will see that the user is already authenticated but does not have the necessary authorization and fail with a 403 error.
In different applications use the roles user, USER and manager then the logging-in application must set up all three roles when it authenticates.

SAML 2.0 protocol exposed as Web Service

I want to implement an SSO system with SAML 2.0 protocol using WSO2 IS as Identity Provider. I've analyzed the SSO sample https://docs.wso2.com/display/IS500/Configuring+Single+Sign-On+with+SAML+2.0 to learn how to implement the Service Provider side to generate an SAML 2.0 authentication request. AFAIK another ways to implement the SAML SP would be using either OpenAM, OpenSAML or Shibboleth. But all those methods require programming knowledge from the Service Provider to implement it.
Thus my question:
Is there any Web Admin Service in WSO2 IS to ease the implementation of a SAML SP? I've find out the SAML2SSOAuthenticationService.wsdl but I'm not sure how it works and whether I need some other Admin Services in order to implement the desired solution.
You can use https://localhost:9443/services/IdentityApplicationManagementService admin service createApplication method to create the service provider.
or You can create service provider using configuration files.
please follow the setps below
1) Open the /repository/conf/security/sso-idp-config.xml file and add the following configuration to it. This adds the travelocity application as a service provider.
<ServiceProvider>
<Issuer>travelocity.com</Issuer>
<AssertionConsumerService>http://localhost:8080/travelocity.com/home.jsp</AssertionConsumerService>
<SignAssertion>false</SignAssertion>
<SignResponse>false</SignResponse>
<EnableAttributeProfile>true</EnableAttributeProfile>
<IncludeAttributeByDefault>true</IncludeAttributeByDefault>
<EnableSingleLogout>true</EnableSingleLogout>
<Claims>
<Claim>http://wso2.org/claims/givenName</Claim>
</Claims>
<LogoutUrl></LogoutUrl>
<EnableAudienceRestriction>false</EnableAudienceRestriction>
<ConsumingServiceIndex>2104589</ConsumingServiceIndex>
</ServiceProvider>
2) Create a file named travelocity.com.xml in the /repository/conf/identity/service-providers directory
3) Add the following configurations into the travelocity.com.xml file you created. This adds the necessary SAML configurations to the travelocity service provider
<ServiceProvider>
<ApplicationID>3</ApplicationID>
<ApplicationName>travelocity.com</ApplicationName>
<Description>travelocity Service Provider</Description>
<IsSaaSApp>true</IsSaaSApp>
<InboundAuthenticationConfig>
<InboundAuthenticationRequestConfigs>
<InboundAuthenticationRequestConfig>
<InboundAuthKey>travelocity.com</InboundAuthKey>
<InboundAuthType>samlsso</InboundAuthType>
<Properties></Properties>
</InboundAuthenticationRequestConfig>
</InboundAuthenticationRequestConfigs>
</InboundAuthenticationConfig>
<LocalAndOutBoundAuthenticationConfig>
<AuthenticationSteps>
<AuthenticationStep>
<StepOrder>1</StepOrder>
­­<LocalAuthenticatorConfigs>
<LocalAuthenticatorConfig>
<Name>BasicAuthenticator</Name>
<DisplayName>basicauth</DisplayName>
<IsEnabled>true</IsEnabled>
</LocalAuthenticatorConfig>
</LocalAuthenticatorConfigs>­­>
<FederatedIdentityProviders>
<IdentityProvider>
<IdentityProviderName>identityProviderIDP_IS</IdentityProviderName>
<IsEnabled>true</IsEnabled>
<DefaultAuthenticatorConfig>
<FederatedAuthenticatorConfig>
<Name>SAMLSSOAuthenticator</Name>
<DisplayName>samlsso</DisplayName>
<IsEnabled>true</IsEnabled>
</FederatedAuthenticatorConfig>
</DefaultAuthenticatorConfig>
</IdentityProvider>
</FederatedIdentityProviders>
<SubjectStep>true</SubjectStep>
<AttributeStep>true</AttributeStep>
</AuthenticationStep>
</AuthenticationSteps>
</LocalAndOutBoundAuthenticationConfig>
<RequestPathAuthenticatorConfigs></RequestPathAuthenticatorConfigs>
<InboundProvisioningConfig></InboundProvisioningConfig>
<OutboundProvisioningConfig></OutboundProvisioningConfig>
<ClaimConfig>
<AlwaysSendMappedLocalSubjectId>true</AlwaysSendMappedLocalSubjectId>
<LocalClaimDialect>true</LocalClaimDialect><ClaimMappings><ClaimMapping><LocalClaim><ClaimUri>http://wso2.org/claims/givenname</ClaimUri></LocalClaim><RemoteClaim><ClaimUri>http://wso2.org/claims/givenName</ClaimUri>ClaimUri></RemoteClaim><RequestClaim>true</RequestClaim></ClaimMapping></ClaimMappings></ClaimConfig>
<PermissionAndRoleConfig></PermissionAndRoleConfig>
</ServiceProvider>
please refer this link for more details
[1] https://docs.wso2.com/display/IS500/Adding+a+Service+Provider+and+Identity+Provider+Using+Configuration+Files

How to download or know the URL of WSO2 Identity Server's SAML metadata?

What would be the URL for the newly set up SAML SSO's metadata URL, or how could I download this in XML format from WSO2 Identity Server (version 4.6.0) acting as IdP?
Thanks,
Tamas
WSO2 Identity server now hosts IDPSSODesriptor metadata file on this URL.
https://localhost:9443/identity/metadata/saml2
This feature is available from Identity Server version 5.3 onward.
AFAIK there is no option to auto-generate metadata files for IS. You have to manually write the metadata file. An example is as follows, taken from this blog post.
<md:entitydescriptor entityid="https://localhost:9443/samlsso" validuntil="2023-09-23T06:57:15.396Z" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<md:idpssodescriptor protocolsupportenumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<md:keydescriptor use="signing">
<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>
</md:keydescriptor>
<md:singlelogoutservice binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" location="https://localhost:9443/samlsso" responselocation="https://localhost:9443/samlsso">
<md:singlesignonservice binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" location="https://localhost:9443/samlsso">
<md:singlesignonservice binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" location="https://localhost:9443/samlsso">
</md:singlesignonservice></md:singlesignonservice></md:singlelogoutservice></md:idpssodescriptor>
</md:entitydescriptor>
Yes.. Identity Server does not support to generate a IDP information as metadata file. You may need to create it manually. But I guess it would be available with a future release. There is an open public jira for this. You can find a generated SAML2 metadata file from here. However you may need to configure it according to your configurations. If you have changed your keystore, you need to change the X509 certificate data. And also urls of the samlsso endpoint. By default saml sso end point is located at https://localhost:9443/samlsso. In your service provider config, you need to configure this url as IDP url (both login and logout). You must provide the wso2carbon certificate in to service provider for validating the signature.