Skip to main content

Setup SSO in WSO2 product with other Identity provider except WSO2IS

This blog post will provide instruction on how to setup SSO, WSO2 DAS server with WSO2 IS.
http://amalkas.blogspot.com/2016/01/setup-sso-with-wso2das-300-portal.html

If you want to setup SSO in WSO2 product with different identity provider. you should consider the following.

Let's say we want to configure WSO2 Greg with ADFS.
1. Configure SSO in Greg updating following configurations in <GREG_HOME>/repository/deployment/server/jaggeryapps/publisher/config/publisher.json

"authentication": {
"activeMethod": "sso",
"methods": {
"sso": {
"attributes": {
"issuer": "publisher",
"identityProviderURL": "<identityProviderURL>",
"responseSigningEnabled": "true",
"acs": "%https.host%/publisher/acs",
"identityAlias": "<identityAlias>",
"useTenantKey": false
}
},
"basic": {
"attributes": {}
}
}
},
view raw JSON_payload_2 hosted with ❤ by GitHub
2. Then configure SSO in ADFS and import the ADFS signing cert into the Greg's JKS.
3. Once we setup the SSO, when login to the Greg, it will redirect to the ADFS, then ADFS will authenticate the user and return the SAML assertion.
4. Then authorization should be happen in Greg side. But it will fail, since the user does not exist in Greg side.

to solve that issue I could find number of solutions assuming you can't share the ADFS user base with GREG:
a: We can create a replica of the user base of ADFS (without passwords/ with dummy password) and Greg pointing to the replica

b: When adding user to the ADFS side, add the same user (without passwords/ with dummy password) and roles to the Greg side. either via a provisioning app, script or manually.

c: Write a JIT provisioning extension to provision the user in GREG side (when the Greg receive the SAML assertion) and authorize to the application.
https://docs.wso2.com/display/IS510/Writing+an+Outbound+Provisioning+Connector


Hope this will help

Labels

Labels:

Comments

Post a Comment

Popular posts from this blog

How to generate random unique number in SOAP UI request

eg 1: ${=System.currentTimeMillis() + ((int)(Math.random()*10000))} eg 2: ${=java.util.UUID.randomUUID()} ${=java.util.UUID.randomUUID()} ${=System.currentTimeMillis() + ((int)(Math.random()*10000))} - See more at: http://tryitnw.blogspot.com/2014/03/generating-random-unique-number-in-soap.html#sthash.m2S4tUFu.dpuf ${=System.currentTimeMillis() + ((int)(Math.random()*10000))} - See more at: http://tryitnw.blogspot.com/2014/03/generating-random-unique-number-in-soap.html#sthash.m2S4tUFu.dpuf ${=System.currentTimeMillis() + ((int)(Math.random()*10000))} - See more at: http://tryitnw.blogspot.com/2014/03/generating-random-unique-number-in-soap.html#sthash.m2S4tUFu.dpuf
Post a Comment
Read more

WSO2 ESB communication with WSO2 ESB Analytics

This blog post is about how & what ports involved when connecting from WSO2 ESB to WSO2 ESB Analytics. How to configure: This document explains how to configure it https://docs.wso2.com/display/ESB500/Prerequisites+to+Publish+Statistics Let's say we have WSO2 ESB  and WSO2 ESB Analytics packs we want to run in same physical machine, then we have to offset one instance.  But we don't want to do that since WSO2 ESB Analytics by default come with the offset. So WSO2ESB will run on 9443 port, WSO2 ESB Analytics will run on 9444 port WSO2 ESB publish data to the WSO2 ESB Analytics via thrift. By default thrift port is 7611 and corresponding ssl thrift port is 7711 (7611+100), check the data-bridge-config.xml file which is in analytics server config directory .  Since we are shipping analytics products with offset 1 then thrift ports are 7612 and ssl port is 7712. Here, ssl port (7712) is used for initial authentication purposes of data publisher ...
Post a Comment
Read more

Tips on using environment variables in WSO2 Integration Cloud

Environment variables allow you to change an application's internal configuration without changing its source code. Let’s say you want to deploy the same application in development, testing  and production environments. Then database related configs and some other internal configurations may change from one environment to another. If we can define these configurations as an environment variables we can easily set those without changing the source code of that application. When you deploy your application in WSO2 Integration Cloud, it lets you define environment variables via the UI. Whenever you change the values of environment variables, you just need to redeploy the application for the changes to take effect. Predefined environment variables Key Concepts - Environment Variables   provides you some predefined set of environment variables which will be useful when deploying applications in WSO2 Integration Cloud. Sample on how to use environment variables ...
Post a Comment
Read more