I have changed default database from H2 to PostgreSQL following the [WSO2]https://is.docs.wso2.com/en/latest/setup/changing-to-postgresql documentation and created tables using the db scripts.
I am able to run the WSO2 identity server and able to add the users using the management console.
But I can't see those users list in um_user table of postgreSQL. Even I can't find those users list in H2 Database also.
Find my deployment.toml file.
[database.identity_db]
type="postgre"
url="jdbc:postgresql://localhost:5432/wso2_identity_db"
username="postgres"
password="postgres"
[database.identity_db.pool_options]
maxActive="80"
maxWait="60000"
minIdle="5"
testOnBorrow=true
validationQuery="SELECT 1;COMMIT"
validationInterval="30000"
defaultAutoCommit=true
[database.shared_db]
type="postgre"
url="jdbc:postgresql://localhost:5432/wso2_shared_db"
username="postgres"
password="postgres"
[database.shared_db.pool_options]
maxActive="80"
maxWait="60000"
minIdle="5"
testOnBorrow=true
validationQuery="SELECT 1;COMMIT"
validationInterval="30000"
defaultAutoCommit=true
I am using the following versions of wso2 and postgreSQL.
WSO2 version = 5.9.0
PostgreSQL Version = 12
Can someone help me to debug this issue?
The identity DB stores the identity-related data such as tokens. Shared DB is responsible for storing registry data. But users are stored in a different location. They are user stores.By default users are stored in ReadWriteLDAP user store. As per your requirement you need to configure a JDBC user store as the primary user store. Please refer to the following documentation. It has the specific configurations related to PostgreSQL user store
https://is.docs.wso2.com/en/5.9.0/setup/configuring-a-jdbc-user-store/
Related
I am trying to register users, client and peers in Hyperledger Fabric network using Postgres as database and using LDAP for authentication.
Although I'm able to generate certificates successfully and everything is working well but still while i check into the Postgres database then the users table is empty and there is no entry in that table, while certificates table is propagated properly and have all the certificates that I have generated.
I have checked postgres database without integrating it with LDAP and then the users table is updating successfully and I can see user entries there.
Is it a normal behavior or I'm missing something?
I have a backup file from db2 express-c 11.1 version and I'd like to restore it into db2 developer version (both on Windows machine). The RESTORE completed successfully and I can list the tables from the db2 command line
db2 list tables for schema XYZ
but when I'm trying to access the data I'm getting the following error message
SQL0551N The statement failed because the authorization ID does not have the
required authorization or privilege to perform the operation. Authorization
ID: "DB2USER". Operation: "SELECT". Object: "XYZ.Table1". SQLSTATE=42501
I logged in as the user who RESTORE the database. WHat's the issue here?
When restoring a DB2-luw database backup to a different Db2-instance , it is wise to first set a Db2-registry variable on the target Db2-instance before performing the database-restore. The account performing the Db2-restore will then be granted SECADM, DBADM, DATAACCESS, and ACCESSCTRL authorities on the restored database.
db2set DB2_RESTORE_GRANT_ADMIN_AUTHORITIES=on
More information here.
Then perform the Db2-restore command.
If you have not taken this action then you can also use manual GRANT statements (on database level and object level) to adjust to the new Db2-instance, but for best results you should use the registry variable above.
You can also use the TRANSFER OWNERSHIP statement at various levels to achieve the security model. Details here. This is useful when the previous owner was the Db2-instance and the restored-database is in a different Db2-instance than the backed-up-database.
I have a firebird database in a .fdb file, but the database do not have the SYSDBA user and I don't remember the credentials to login into the database. Are there any way that could reset the database credentials?
Like said by Mark, it is not that the database "does not have SYSDBA user" - databases in Firebird 2.x never have users - but that old trick was used to create SYSDBA named role in order to trigger names collision on login.
After scanning through 2007 Security presentation I have two suggestions for you.
You can try some tool that opens Firebird databases without using Firebird itself to learn what username can pull you out of the deadlock.
One such tool is Database Explorer in the IBExpert. Full IBExpert is paid for non-USSR states and free IBExpert Personal probably does not have the tool. But I hope the tool works in IBExpert Trial. Another tool is IBSurgeon FirstAID. And probably there are more tools featuring data extraction from corrupt databases. You only need to find and read one specific row.
The query to create the blocking role is given on the 23rd page of the presentation.
INSERT INTO RDB$ROLES(RDB$ROLE_NAME, RDB$OWNER_NAME)
VALUES (‘SYSDBA’, ‘LOCKSMITH’);
So you would have to look into the said table, find the row with the said role, and learn the username that has authority over that role (in the example it was LOCKSMITH).
After that you connect to any other database on the same server and you create the user with the name you learnt. Then you use that name to login into the problematic database and to DROP ROLE SYSDBA; COMMIT;.
You also can use Firebird Embedded. All server-coded security checks are bypassed in the Embedded edition of FB 2.x (but if DB designer added some ad hoc security checks in triggers - they will work). So you login into the problematic database using Firebird Embedded edition, any username and any password, and after that you drop the access blocking role.
In Firebird database doesn't contain password (until v3.0 as mentioned by #Arioch'The). The password is used only for server. Another words, you can copy database file from existed server to another (with known password) and open the database file.
DreamFactory installer (via php artisan) is prompting "Enter your database name:", not sure what database means, it wants me to set a brand new database name or a name for existing one?
You need to provide a database for DreamFactory to use to store its configuration options and users. This can be sqlite, mysql, postgres, or sql server (paid option.)
When you run the setup command you need to provide the database connection information for an existing database. If you don't have a database, you can choose the sqlite option instead of one of the others. sqlite is file based and requires no server infrastructure. The database will be created for you automatically in that case.
I created a Firebird database by an account other than sysdba. If I put a copy of this db to another machine, I can open it by sysdba account and the 'masterkey' password. Thus this is real risk if some one can take a copy of it.
Is there some way to prevent this scenario?
The user that created a database is "just" the owner of the database, the sysdba user is administrator and is allowed to do anything to all databases on a Firebird server. This is a very good reason to never use masterkey as your password on a production server.
The usernames and passwords in Firebird 2.5 and earlier are stored in a security database (security2.fdb) that is part of the Firebird installation. So moving a database to another server (or replacing the security2.fdb) will allow "unauthorized" persons to access the database. Note that I put unauthorized in quotes here, because if a person has direct file access so they are able to make a copy of the database, or replace the security2.fdb, they have sufficient authorization on your server to do anything they want (or the security of your system has been breached).
In Firebird 3, it will be possible to store users in the database itself, but this still requires server-side configuration, so - as far as I know - this will not restrict much in this scenario. Firebird 3 will also provide support for database encryption which could allow you to only give access on a specific server, or with users that provide a specific key. Unfortunately Firebird 3 only provides the API, but not the encryption. That is left to users or library providers to implement.
There is also a trick to create a role with the name SYSDBA in your database which will prevent a user with username sysdba to connect to the database. But this is easy to circumvent by using a hex editor and some knowledge of the internal structure of a Firebird database to undo this. If the person really wants access to your data, they can also just compile a Firebird server that skips or ignores authentication.
All in all, this means that if someone has direct access to the database file, then they can create a copy and open it on another Firebird install one way or another. So the only real way to protect a database file is to make sure that users can only access the database through the Firebird server, don't have direct access to the database files and - except admins - are not able to create a backup of the database.
Even if users only have access through the server, they can still make a logical copy of the entire database structure, and all data they are allowed to access.
Consider reading Firebird File and Metadata Security