wso2 maintains user token information in it's internal database. This would be a problem when a access token is sent to another wso2 IS for validating authentication, i.e when wso2 IS is behind a load balancer.
Any idea where/how to configure wso2 IS to maintain the user authorization/authentication tokens in a central database?
You can configure a centralized DB for both IS nodes. What you have to do is change the master-datasource.xml inside <IS_HOME>/repository/conf/datasources to point to the correct DB. And it is not recommended to use the given internal H2 DB in production.
Related
I developed a website using django. Recently I am trying to make it serverless ( by deploying to lambda ). I haven't figured out how to maintain the session after user logged in when deployed to lambda.any suggestions please.
As you probably know, lambdas are stateless. You can use some database i.e. Dynamo DB to store and retrieve session related information, i.e. connection token. Otherwise you can integrate with AWS Cognito service which handles authentication and session information for you.
Most session capabilities inherent to Django will work fine with a zappa deployed Django project as long as the appropriate infrastructure is available. For example if you choose database-backed session, then your Django deployment must have access to a database. But you must avoid File-based sessions since you cannot guarantee the file will exist for any given user request (the lambda container to which requests are routed are not deterministic).
For more information on Django sessions see the documentation
We are evaluating WSO2 Identity Server, and are trying to understand how WSO2 Identity Server scales across multiple nodes.
The document https://docs.wso2.com/display/CLUSTER44x/Clustering+Identity+Server+5.1.0+and+5.2.0 explains steps to follow to enable clustering, however the document links to database setup documentation that is common to the whole WSO2 suite, and not specifically for Identity Server.
I understand from the documentation that all WSO2 Identity Server nodes are required to share a set of clustered LDAP servers (when an LDAP server is in use).
Is each node in a WSO2 Identity Server cluster required to share a set of clustered SQL servers in addition to the above?
Alternatively, is it fine to have each node use a local database in the expectation that WSO2 Identity Server will communicate with other members of the cluster in order to keep all databases in sync?
When clustering wso2 products, you can use a local db for WSO2CarbonDB (This will be used to store instance-specific data) But you have to share registrydb, userdb among all the nodes.
AFAIK wso2 will not do the db syncing if you use separate db for each node.
I am making a RemoteRegistry connection to a WSO2 server as user admin, but I am in need of being able to create registry resources as a different user (so the owner of the resource is not admin but another existing user). Is it possible to impersonate another user, or obtain a Registry instance for another user?
This is possible for code that runs inside the WSO2 (for example, code deployed in the built-in Tomcat instance that WSO2 itself runs on), but this particular requirement is for code that accesses the WSO2 server remotely via external APIs, rather than directly from within.
The WSO2 server in question is a WSO2 Identity Server v5.x that also includes functionality from WSO2 Governance Registry.
Such as two factor authentication, 3rd party OAuth, Connecting to LDAP.
I have added the above security to Wso2 Identity Server. But please help me achieve the same with Wso2 ESB.
Thanks
Where you want to add the security? What you want to secure?
I see two parts where the user security may play role in ESB:
For the carbon (management) console, I may disappoint you, that may not be so simple. See the Custom carbon authentication . It seems you need to enable other authenticators or add your own (see the file authenticators.xml, they are disabled by default) and "patch" the carbon to use it. However - for our best practices the management console (and the management services) should be not accessible from untrusted network .
If you're talking about securing the web services, this is not something an end user (person) is accessing. Ok - excluding the REST services. There are multiple options available to secure web services. From basic authentication (and username token), to STS (security token service), signing and encrypting the payload. See Securing web services, however here we assume some knowledge about the service security.
We want to connect WSO2 API Manager to WSO2 Identity server for application key management, so in other words we don't want to use the embedded key management that comes with API Manager, how can we achieve that?
IS is used as Oauth provider, but if we think about key management part, we have no of operations managed by APIM, to restrict /allow token accesses..
So, if you want to use IS as keymanagement server, you need to install APIM key-management related features in IS and in the api-mgt.xml,you have to provide IS server URL/credentials under APIKeymanagment section.