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.
Related
I want to build a site hosted with Spring Boot and I would like to use AWS SSO as the SAML identity provider for authentication. I have built a PoC application and tried to follow AWS configuration instructions and the Spring SAML examples I could find, but when I browse to my site (on localhost), AWS SSO successfully opens but then fails with "Bad Input".
In my PoC application (which only has code for the authentication and an index page) I have:
added the spring-security-saml2-service-provider dependency (Spring Boot v2.6.2)
set up a Custom Application in AWS SSO
generated a private key and a self-signed certificate
configured my application properties as follows:
spring:
security:
saml2:
relyingparty:
registration:
metadata:
signing.credentials:
- private-key-location: classpath:key.pem
certificate-location: classpath:cert.pem
identityprovider:
metadata-uri: https://portal.sso.eu-west-1.amazonaws.com/saml/metadata/my-custom-applications-metadata-uri
and my configuration file has these beans:
#Bean
RelyingPartyRegistrationResolver relyingPartyRegistrationResolver(
RelyingPartyRegistrationRepository registrations) {
return new DefaultRelyingPartyRegistrationResolver((id) -> registrations.findByRegistrationId("metadata"));
}
#Bean
FilterRegistrationBean<Saml2MetadataFilter> metadata(RelyingPartyRegistrationResolver registrations) {
Saml2MetadataFilter metadata = new Saml2MetadataFilter(registrations, new OpenSamlMetadataResolver());
FilterRegistrationBean<Saml2MetadataFilter> filter = new FilterRegistrationBean<>(metadata);
filter.setOrder(-101);
return filter;
}
then, I have downloaded the metadata from my spring boot application (via http://localhost:8080/saml2/service-provider-metadata/metadata) and entered it into the AWS custom application config. This set the ACS to http://localhost:8080/login/saml2/sso/metadata and audience to http://localhost:8080/saml2/service-provider-metadata/metadata which seems correct. My Application start URL and Relay States are blank. In the Attributes Mapping I have set Subject to ${user.email} with format emailAddress.
I have used the SAML-tracer plugin to try to figure out what happens when I make a request to localhost:8080/. We end up making a SAML POST (see below) to AWS, AWS reroutes to GET https://portal.sso.eu-west-1.amazonaws.com/token/whoAmI which succeeds, and then finally reroutes to GET https://portal.sso.eu-west-1.amazonaws.com/saml/v2/assertion/very-long-id which fails with 400 Bad Request which lands us on a page in AWS SSO where something went wrong with the message {message: "Bad input", __type: "com.amazonaws.switchboard.portal#InvalidRequestException"}. I tried checking CloudTrail to find more info but it just logs the events AssumeRoleWithSAML followed by ConsoleLogin which both succeed. This is the SAML data as displayed by SAML-tracer which my application POSTs to AWS (replaced info that may be sensitive):
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="http://localhost:8080/login/saml2/sso/metadata"
Destination="https://portal.sso.eu-west-1.amazonaws.com/saml/assertion/insert-long-id"
ID="a-long-id"
IssueInstant="2022-01-10T13:59:52.963Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0"
>
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:8080/saml2/service-provider-metadata/metadata</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:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<ds:Reference URI="#Anot-sure-if-secret-random-characters">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>some-more-characters</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>a-long-base-64-encoded-block-of-characters</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>a-long-encoded-certificate</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</saml2p:AuthnRequest>
I have tried to find more information on how AWS SSO expects the data to be sent or what "Bad Input" actually means, but it has been really difficult to find. I have also experimented a bit with trying to send the request without signing with my priv key/cert but that didn't seem to get me anywhere. I am suspecting that either the key/cert process is wrong or that I have not set up AWS correctly, but I am not sure how to proceed. Does anyone have any ideas?
The issue is that the ACS url is set to localhost. The ACS (Assertion Consumer Service) URL is where the IdP sends the SAML Assertion.
You're telling AWS SSO to send the SAML assertion to itself, which isn't going to work. Your application needs a public-routable IP. AWS SSO needs to send the SAML assertion over the internet.
There may be other issues (I didn't really check anything once I ran into the ACS issue). But the ACS URL is your current issue.
The error was that the IdP certificate wasn't added to the spring application.
To do this, download the AWS certificate in AWS SSO when configuring your custom application, then put that certificate at src/main/resources/credentials/idp-certificate.crt.
Everything worked well after this step, including using localhost ACS URLs.
I wrote a short tutorial on how to do it at https://maxk.se/posts/aws-sso-spring-boot/
After I installed WSO2 EEM (Enterprise Mobility Manger), I could add device to device management. But I couldn't open the Publisher/Store, all the page will jump to the https://localhost:9443/publisher/acs or https://localhost:9443/samlsso. Should I to install the WSO2 Identity Server or config the SSO for it?
You don't need to install any identity components or configure sso explicitely. They are already there in vanilla EMM. When you go to https://localhost:9443/publisher, it should be redirected to login page.
https://localhost:9443/authenticationendpoint/login.do
Then when you enter credentials it should redirect you in below urls.
1) https://localhost:9443/publisher/acs
2) https://localhost:9443/publisher
If this doesn't work for you, there should be exceptions in log file. Please check that.
There was a missing part in EMM documentation in the SSO configuration section[1]. Hope you are trying out this VM. Please follow the steps which are given in here in order to get publisher and store working properly.
The reason which you encountered becuase of app-manager.xml file that is in the /repository/conf directory didn't properly configure.
<SSOConfiguration>
<!-- URL of the IDP use for SSO -->
<IdentityProviderUrl>https://<EMM_HOST>:<EMM_HTTPS_PORT>/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://<EMM_HOST>:<EMM_HTTPS_PORT></providerURL>
<username>admin</username>
<password>admin</password>
</parameters>
</Configurator>
</Configurators>
</SSOConfiguration>
1.https://docs.wso2.com/display/EMM201/General+Server+Configurations
When testing the WSO2 identity server rel. 5.1 using the Travelocity tool, I see a number of error messages recorded in the log file, telling:
"Server is not picking up the client certificate. Mutual SSL authentication is notdone"
The message repeats every 3 minutes.
Where is the missing certificate stored that needs to be updated to connect the Travelocity to the WSO2 IdP without writing error logs? In the travelocity.jks store at the client side, I currently see an alias entry for localhost and another entry for the IDP.
I've raised the debug level at the log4j.properties to the values:
log4j.logger.org.wso2.carbon.user=DEBUG
log4j.logger.org.wso2.carbon.identity=DEBUG
log4j.logger.org.wso2.carbon.idp.mgt=DEBUG
This is actually not an error log. This is a debug log. If you removed the following debug level entry from the log4j.properties file you will not see this.
log4j.logger.org.wso2.carbon.identity=DEBUG
MutualSSLAuthenticator is a carbon authenticator which is shipped by default with WSO2 IS 5.1.0. This authenticator is by default enabled from the authenticators.xml file located at
IS_HOME/repository/conf/security/ directory. This is actually not getting invoked by the SAML authentication flow, or OpenID flow which you might be trying with the Travelocity sample application. But, the log gets printed as the framework checks if the authenticator is capable of handling the authentication.
This authenticator is used with the OOTB supported Workflow Management Feature [1], for server to server authentication.
You can also disable this authenticator by commenting out the below configuration at authenticators.xml file, and yet, authentication with Travelocity sample application will work successfully.
<Authenticator name="MutualSSLAuthenticator">
<Priority>5</Priority>
<Config>
<Parameter name="UsernameHeader">UserName</Parameter>
<Parameter name="WhiteListEnabled">false</Parameter>
<Parameter name="WhiteList">
</Config>
</Authenticator>
[1]https://docs.wso2.com/display/IS510/Workflow+Management
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.
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