When there is a domain created and username and password for the domain is registered to chat on the XMPP. Where does these username and password be saved.
Are these stored on Jabber server's database, or we create a database on our server and store them.
Like sunil#sunil.com is stored in jabber server database or on sunil.com database.
Any link to through more light on this will also be help full
Cheers
Sunil
That depends on the Jabber server used. Some Jabber servers are able to store the usernames and passwords in an internal database, but most server implementations also let you configure an external database, such as MySQL or Postgres, or let you use LDAP for the user database.
Related
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.
I am new to tableau and I want to integrate tableau server in our application through Iframe, I am passing HTTP URL with authentication details like username and password but whenever I am accessing tableau it is asking for username and password.So please suggest me that how i can access tableau without redirecting to login page.
According to the Tableau community you can't do this through the URL:
There is no built-in mechanism to pass a username/password on the URL
as doing so gives "bad people" a super-duper-easy way to hack into
Tableau Server itself. As a hacker, all I'd have to do is "sit on the
wire", watch requests go to Tableau, and I could harvest everyone's
usernames and passwords. Scary stuff!
But there is a solution for built in credentials if you have a security mechanism on your end:
You might want to read up on Tableau Server's ability to do Trusted
Tickets authentication. You could essentially tell Tableau Server to
"Trust" whatever other security mechanism is authenticating your users
(I assume you have one). If you don't have another mechaism to
authenticate users before they get to Tableau Server, there's not too
much you can do.
More on Trusted Authentication from Tableau website:
Trusted authentication simply means that you have set up a trusted
relationship between Tableau Server and one or more web servers. When
Tableau Server receives requests from these trusted web servers it
assumes that your web server has handled whatever authentication is
necessary
Setting this up requires you to add the trusted IP addresses to your Tableau server. This is done by stopping tabadmin and then running the following command, followed by saving this config and restarting:
tabadmin set wgserver.trusted_hosts "<trusted IP addresses or host names>"
Once this is done you have to configure your web server so it can request tickets from Tableau server using a POST request to http://<server name>/trusted. These tickets must then be included into the script.
Hope this helps.
My web application is currently configured to connect to LDAP for user validation without relying on application server settings. In other words, my applications utilizes naming params to connect to LDAP hence its agnostic to application server ie. JBoss or Websphere.
Naming params used are as follows:
ldapURL
ldapPrincipal (bind user)
ldapCredentials (bind user's password)
ldapAuthentication
ldapSearchBase
The requirement now is to allow encrypted password in the ldapCredentials naming param. I have a way out of this situation is using custom SecurityLoginModule to encrypt password and supply it to application using naming param. My application would then decrypt it and then proceed with LDAP user validation. However, this results into additional application installation step.
So I was wondering if there is a way to use application server security domain (or some other way) to store the user credentials in secured fashion on application server and later application would pick it up at the time of user validation with LDAP without writing server specific code in my application. I know that we can use security domain to perform data source connection without writing server specific code. But if I do this for LDAP then I make server talk to LDAP which is not what am looking. Basically may still continue to use Federated users instead of LDAP.
Any decent application server (including JBoss and WebSphere) have server provided LDAP registry, which you can configure and use without any application specific code, and I'd strongly suggest to utilize that instead of writing your own ldap connection code.
Regarding encryption:
for WebSphere traditional, you can plug in your own class into server infrastructure to encrypt passwords see - Plug point for custom password encryption
for WebSphere Liberty - you have out of the box support for aes and hash.
for JBoss first link in Google showed me this How do I encrypt the bindCredential password in Wildfly, but maybe JBoss experts will guide you to something different.
I am using "openfire" as xmpp server. And I am implementing the xmpp client in my APP to provide the chat service to all members. The openfire has its own database said db1. My iOS APP also has its own database said db2. How can I sync up the user tables between these two databases (db1 and db2)? For example, when user signup my APP, I would like to create the same account in xmpp server database. And when user login into my APP service, I would like to have user login into xmpp server automatically.
Don't try to synch the databases, you need to write a custom authentication provider for Openfire to use db2.
As for the login, you will just have to login to both at the same time. It can't be done via the other service since that cannot create a connection between you client and the XMPP server.
I have a service with usernames and passwords already set up that I want to add a Jabber service to.
Is there any open source XMPP servers that I can customise to use my existing usernames and passwords in a Postgres DB?
You can do this with Openfire. You can either write your own extension to support a custom authentication mechanism, or you might be able to manage it with some simple configuration (check the section on Authentication Integration).