Is it possible to instruct the jabber/xmpp server to delegate authentication to another module? We are building an internal application using XMPP and it would be fantastic if we could let users keep their standard username/password that they use in our web-apps. The web-apps are currently hashing passwords, and so the passwords in the DB are not stored in plain-text form. It would have been easy to share passwords across systems if this were not the case, but then, of course, storing plain-text passwords in the server-side database is a big no-no.
Ideally we could just tell the jabber server "hey, just pass off your username/authentication request to here" and have some other process running (perhaps even just an xmpp bot?) that handles authentication.
We are currently using ejabberd as our server, which I believe is written in Erlang. We're not tied to ejabberd though. I know that XMPP is huge, and largely extensible - but I haven't found anything about extensible authentication on the server side.
I found this on the XMPP website, but that appears to be the protocol for negotiating authentication between the client and the server, not the actual authentication mechanism on the server.
Any pointers on how to merge authentication schemes between an XMPP server and our other systems?
ejabberd has multiple ways to authenticate. You can use LDAP, for example, if you have an LDAP server for your organisation. This works at my company, and provides a single log in for our wiki, ticket system, etc.
Have a look at the section on authentication in the user guide.
Related
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
Worklight 6.1 documentation identifies that "credentials" such as password can be added to the user identity object (UIO) provided to WL.Server.setActiveUser().
How & where is the UIO stored on the WL server, and is this considered a secure storage?
Trying to understand the security implications of storing password in this structure to be retrieved and used for subsequent back-end access (Cloud) requests. If not secure, can encryption be applied to the any part of the UIO?
Appreciate any advice you can provide.
The User Identity object is kept in memory and is scoped to the current session.
In other words, the credentials are not persisted; one would need to dump the server memory and dig through it or connect with a debugger. It's considered secure. The production server is also supposed to run in a secure environment with limited access to the process, etc... of course.
The credentials stored in this object can be used by the adapter to authenticate with a back-end on behalf of the user.
In a HTTP adapter, the authentication schemes Basic, Digest and NTLM use that technique
In non-HTTP adapter and in custom authentication schemes, the developer can use those credentials as necessary.
I need to build a scalable single sign-on mechanism for multiple sites. Scenario:
Central web application to register/manage account (Server in Europe)
Several web applications that need to authenticate against my user database (Servers in US/Europe/Pacific region)
I am using MySQL as database backend. The options I came up with are either replicating the user database across all servers (data security?) or allowing the servers to directly connect to my MySQL instance by explicitly allowing connections from their IPs in my.cnf (high load? single point of failure?).
What would be the best way to provide a scalable and low-latency single sign-on for all web applications? In terms of data security would it be a good idea to replicate the user database across all web applications?
Note: All web applications provide an API which users can use to embed widgets into their own websites. These widgets work through a token auth mechanism which will again need to authenticate against my user database.
I would not integrate the authentication on the database level, as in replicating the db or allowing access from the other servers. This might become hard to maintain. I would prefer a loosely coupled approach by exposing a simple service on your central server that lets the other app servers run authentication requests.
You should look into the following issues (probably more):
How to avoid cleartext transmission of passwords between servers
You probably can't throttle the service if a network of application servers authenticates all their users from the same IP, so you might want to restrict access to certain clients to avoid rogue machines mass-probing for valid accounts.
How to centrally enforce things such as session expiration
How to handle / avoid service downtime
Techniques that might be helpful:
Cryptographic CRAM (to avoid password transmission)
Certificates (to prove the clients' identity)
Alternatively, you might want to have the clients use the central service to obtain a token that is then promoted to and verified by the target server. There's architectures that work similarly (e. g. Kerberos ticket servers) which may serve as inspiration.
You should go for Oauth2 or SAML.
Several sites, including this one, are using OpenID to authenticate their users. And of course, OpenID is a good solution to manage user accounts, simply by linking them to their OpenID account.
But are there similar solutions that could be used for desktop applications? I know there's CardSpace, where you create a custom ID card to contain your identity and optionally protect it with a pincode. But are there more alternatives for authentications on a desktop system or on systems within a local intranet environment?
And yes, I can write my own system where I keep a list of usernames and (hashed) passwords and then build my own login system but I just hate to invent my own wheel, especially when I need to keep it secure.
I would recommend that you look into the option of building an STS (using WIF, aka Geneva) and use (active) WS-federation in your windows app. Or if you can wait that long, just use Geneva Server when that is released.
We have a solution that works more or less like this:
Desktop tool prompts the user for ID/password
Desktop tool sends the ID/password over an encrypted (SSL) channel to the server.
Server initiates an HTTP request to a known URL of a login form and inputs the username and password as if they were form fields.
If the HTTP server responds appropriately, the server accepts the client as authenticated.
The target of that HTTP request should be tied to whatever single sign-on system that you use for the web application environment. In our case it happens not to be OpenID but it could be.
From Wikipedia: RSA SecurID is a mechanism developed by RSA Security for performing two-factor authentication for a user to a network resource.
I just read about this device, and it seems interesting to me. However, I'm not sure how (or even if) software (networked or non-networked) can utilize this method of authentication.
I'm making this a community wiki post as this isn't a specific question, but a general overview of addressing authentication with SecurID and similar technologies.
There's a similar technology called YubiKey.
Verisign's OpenID provider supports such tokens (sold at a discount by EBay and PayPal), which is certainly the easiest way to get started using dual-factor authentication for web applications.
To actually answer the original question, there are several ways to integrate with SecurID, from "simplest" to "requires a bit more work":
See if the application is already integrated/certified. A list of applications that have been integrated and validated by RSA can be found at http://www.rsasecured.com. Only applications that have opted to be validated are listed; it's possible that an application can integrate but has not undergone validation.
Leverage one of the existing RSA Authentication Agents (pieces of code that talk to the Authentication Manager server) and that integrate, for example, with the OS/Application Server/Web server, so that the authentication can be "offloaded" to the agent, and the application only has to take care of the core functionality. The Agents that RSA develops can be downloaded from http://www.emc.com/security/rsa-securid/rsa-securid-authentication-agents.htm (RSA is the Security Division of EMC).
If the application/device can leverage the RADIUS protocol for external authentication (see http://en.wikipedia.org/wiki/RADIUS), the Authentication Manager server is also a RADIUS server.
Lastly, if you want to integrate the application directly with RSA, the RSA SecurID Agent SDK allows you to embed the needed functionality in the application itself, so the app can talk directly to the Authentication Manager server, send authentication requests, receive the answers, leverage the HA functionality of the authentication server etc... This is how devices such as VPN SSL Concentrators, Firewalls, and many many others integrate (see the list in point 1).
Hope this helps
My company, WiKID Systems, has a dual-source two-factor authentication system. In addition to radius, ldap etc, we have a very simple API called wAuth and packages available in PHP, Python, Ruby, Java and C#. These 'network client' packages are LGPL so you can put them in open source or commercial licensed software. You can download here. It would be pretty simple to do others too.
Also, we have an open source version of the software token, so you can embed that if you like and you can really see how the system works from end-to-end.