I'm trying to setup multi-factor authentication in WSO2 Identity Server 5.5. As per instructions, I have installed and configured totp as a possible second factor. Within my service provider, I'm attempting to add multiple steps to the Advanced Authentication Configuration screen under the Local & Outbound Authentication Configuration section, and modifications are not saving when pressing Update.
I understand that some of the UI operations do not always operate as expected, so I was wondering if anyone knew how to fix this or perhaps could specify where the service provider config files are located so I can make these changes manually?
For my use case, I just want to have basic as the first step/factor and then totp as the second. Nothing seems to save on this screen.
Thanks.
screenshot-advanced configuration
Related
I have installed WSO2 IS (5.10) and Analytics (5.8), on separate servers, following the WSO2 IS documentation. I am successfully getting authentication events received into Analytics and can view them (after many headaches with IS insisting on using ports and SSL that I never told it to use - another story).
Now I can log into the dashboard, (/portal, admin/admin), and I see the IS events. Where do I manage portal users, permissions, and authentication? I want to add additional viewers (via LDAP) but can't even find a place to change the admin password, never mind manage additional users.
Nor can I find any documentation on how to manager users in Analytics. Any help is appreciated.
Currently, We are using WSO2(v5.8) in our development environment. We have used all the soap request almost of WSO2 - tenant creation, service provider, user store, and claim as well. All the soap requests are working fine. But in case of Claim : the problem is , it created successfully and updated successfully using soap request without any error. When we are going to see the new added claim on wso2 console then the newly added claims are not displaying under claims. After sometime the claims are available, which means we are able to see the newly added claim and we can use it with service provider also.
But most of the time is not displaying. I think the claims are not synced properly in case of multiple instances running of WSO2. Somebody help highly appreciated
Historically WSO2 Identity Server used distributed caching to utilize the above-mentioned advantages as well as to minimize the coherence problem. However, in newer deployment patterns where the network is not tightly controlled, distributed caching fails in unexpected ways. Hence, we no longer recommend using distributed caching. Instead, it is recommended to have local caches.
Refer to this document to get further information about deployment patterns.
In order to enable localcaches, Please check whether you have enabled this property in /repository/conf/carbon.xml file
<ForceLocalCache>true</ForceLocalCache>
For clustered nodes, enabling this property enables local cache invalidations.
[update]
There is a similar issue already reported regarding claims are not listed or not synced properly in a clustered environment when forcelocalcache is enabled. You can refer to the git issue here. This issue is fixed with Identity Server 5.9.0
I recently updated my environment from WSO2 IS 5.0.0 to WSO2 IS 5.2.0. My environment consists of one machine deployed on EC2 AWS instance. I am using MySQL(not the default H2 database). The machine on which the IS is deployed is Windows Server 2012 R2.
I also have a solution which wraps the IS Admin Soap services and allows me to automate some of the processes like:
-- Service Provider creation and configuration
-- User creation and configuration
-- Tenant creation and configuration
After upgrading to WSO2 IS 5.2.0 I started experiencing delays in the responses of the admin SOAP Services. Since I am using AWS I double checked whether I am using the most appropriate region to have the IS machine. Indeed it was - I am using the Frankfurt region.
I decided to do a simple test to see whether there is delay and if so how it affect my applications. So I created a simple Console Application which was hosted on my local machine and configured the Service References first against my new DEV IS 5.2.0 machine(Frankfurt region). For my test purposes I am using RemoteUserStoreManagerService?wsdl and I am trying to create a user. Ran the test several times and it seems that it takes about 6-7 seconds to create user.
Then I used the exact same conditions in order to run the test against DEV IS 5.0.0 machine which is also hosted in the same region (Frankfurt) and is using the exact same machine configuration (t2.large). Once again the Console Application was hosted on my local machine. The result from the second test was - 1 second to create the user using the very same admin SOAP service and the exact same logic in the Console Application under the same conditions the first test was executed.
Please find below image that displays some of the test results:
https://www.dropbox.com/s/h6rrhnczrutmmxw/IS5.2%20vs%20IS%205.0%20SOAP%20Service.png?dl=0
Is this a known behavior, or some sort of configuration should be applied to avoid such delays from the admin SOAP services?
Thanks in advance.
It turned out to be a configuration issue. In the following file:
"[wso2is-5.2.0_HOME]\repository\conf\identity\identity.xml"
There is a section named "EventListeners" and in there the following listener:
<EventListener type="org.wso2.carbon.user.core.listener.UserOperationEventListener" name="org.wso2.carbon.identity.mgt.IdentityMgtEventListener" orderId="50" enable="true"/>
Once I disabled this listener, all my issues regarding the delays in the responses of the SOAP admin services disappeared.
I did basic search to see what is the purpose of this listener and was able ti find the following:
http://pushpalankajaya.blogspot.bg/2016/02/account-deactivation-with-wso2-identity.html
I have recently inherited a Web API development that exposes key endpoints to a company that is hosting and running our website.
We use Octopus to deploy the API to our webserver.
I have duplicated the API and added the appropriate configuration variable to Octopus and deployed it to a secondary webserver (as a development API) for our 3rd party to use.
We are using identity server along with OpenID connect for authentication.
This has built and deployed however authentication is failing.
I know this is a vague description, but I am looking for pointers for an analysis path.
I have compared the logs of the current Api and the test Api and results are the same. (Stating authentication is successful)
Not really enough information to properly answer this question - but I would start by:
1) Checking all the log files you can find for a more detailed exception message. (application logs, IIS logs, event log)
2) Try to narrow down the issue. Does authentication fail for everyone/all the time? Or is this an issue intermittent? Does it work locally? For certain providers only?
3) Slowly start making the new website look like the old website. Comparing web.config files, copy/pasting the old website code onto the new server etc.
4) Check or restore old service accounts, firewall settings, database values, urls etc.
If all else fails - bring everything back to a working state and start changing one thing at a time until you have a little more experience with the application.
I added in claim-config.xml but i dont see that claim being added in the IS management console.
<ClaimURI>http://wso2.org/claims/serialNumber</ClaimURI>
<DisplayName>serialNumber</DisplayName>
<AttributeID>url</AttributeID>
<Description>SerialNumber</Description>
<DisplayOrder>3</DisplayOrder>
<SupportedByDefault />
</Claim>
Also i dont want to add the claim mapping from management console. i want to automate this process so need a configuration change.
WSO2IS reads the claim-config.xml file and add those claims when you start the server first time. After you update the claim-config.xml, It does not read from it. When server is started first time, it reads the claim-config.xml file add add those in to the database (as there are no any claim configuration in the database). If claim mapping are dynamically changed and you do not like to configure them from UI, you can automate the web service API that is used to configure the claims. If claim mappings are not changed, them you can add all the configures in the claim-config.xml in the first start up.
You can use the ClaimManagementService admin service of WSO2 Identity Server to do CRUD operations on claims. You can get an idea of available methods by referring to the wsdl of ClaimManagementService. Please refer to this link for more information regarding calling admin services of WSO2 servers.