Can anyone recommend how to implement SecurID authentication in Linux C++ based application? I I was thinking of the following options:
An apache module for SecurID (we're using Apache on the front-end)
PAM
Some combination of SecurID through Radius that I've heard about but don't understand
Using something like ace-radius together with a RADIUS server seems to me like the easiest solution.
If I recall right RSA provides a RADIUS server in the ACE/SecurID distribution, so this should be easy to setup.
The simplest, fastest way to integrate with SecurID is the SecurID apache module (http://www.emc.com/security/rsa-securid/rsa-authentication-agents/apache-7-1.htm).
Using the RSA SecurID PAM module (http://www.emc.com/security/rsa-securid/rsa-authentication-agents/pam-7-0.htm) is another option, that has the advantage that it'd also provide OS-level OS-level authentication.
The 3rd option would be to integrate RADIUS in your app and have it talk to Authentication Manger, but it's probably as simple if not simpler to use SecurID SDK directly (in C in your case) so that your app talks directly to the Authentication Manager server.
Hope this helps
Related
I need some guides or keywords I can use for my additional research.
Assume there are client and server apps written in C++. There is a possibility to pass blobs from client to server and vise versa. On windows, we can introduce Kerberos utilization, generating, processing such blobs, accepting it, impersonating threads, etc. There are some examples on msdn. It's not so simple, but I've managed to make it work.
But what if my client runs on linux machine? The simplest and unsecured way of authentication is to pass username/domain/password of user in raw format via blobs. But if I want to use Kerberos? So, the questions are:
What preconditions do I need to have on client linux machine? My first thoughts were about some kind of samba/winbind things installed there. I heard samba authenticates to windows AD via Kerberos.
Is there any good examples of performing Kerberos handshake on linux? I know there are some examples on MIT website. Should I use these ones? I guess it's not so easy to make it work in a right way and test it (actually I KNOW it from my windows experience).
The API you should investigate is GSSAPI. If the windows server application uses SSPI ( the windows version of GSSAPI ) then you should be able to write an interoperable client using GSSAPI. It really depends on exactly how the windows server uses SSPI though. See MSDN SSPI for some details.
The MIT kerberos libraries are available with most linux distributions and have all the libraries you need to do GSSAPI with kerberos.
GSSAPI is a library for wrapping data, you still need to implement the resulting protocol exchange. Depending on exactly how the windows server is written this may be quite complex.
It is possible to use Active Directory as your KDC for writing linux client/server kerberos applications. Looking at the Linux Samba code should
help you understand some of the issues involved in writing a linux client
for windows based services.
I'm looking for a library that work exactly like socket.io(node.js) but I need it in other platform, c++ or maybe python.
This is about server application for website. My app work with node.js but I need to change it for C++/python or something other.
socket.io is great because it choose technology automatically to connect with server - depend which browser/hardware you use.
Any ideas?
For Python, you could look into >> Websockets with python <<
Can I use Socket.IO with Django?
Django is a web-framework that uses Python language.
There is a Socket.IO implementation for python via TornadIO2, which is to be used with the Tornado async web server. I have used this when it was TornadIO 1.0
Go has one that I use, but its only compatible to Socket.IO 0.6.x: go-socket.io
And just look at the socket.io Wiki for other links:
https://github.com/learnboost/socket.io/wiki
The protocol definition for socket.io is available here
https://github.com/LearnBoost/socket.io-spec
I have been part of a couple of project where we decided to actually implement our own client for various reasons. It is not that hard especially since you only have to support on transport (xhr-polling is the easiest imho).
And also maybe a possibility to give back to the community....
I have a Django web app that provides a download facility for a private user dropbox by issuing HTTP requests to a lighttpd server using the x-send-file header. I would like to extend this functionality to allow WebDav access from third party clients. Is this possible? The only examples I can see have statically defined WebDav folders.
The only example of a per-user dynamic WebDAV confir I can find is this solution using the Apache LA-U look-ahead feature.
I'd love to extend my Django app for this but the key requirement is to be able to generate a dynamic config. Integration with a third party solution would be OK.
Any suggestions?
Michela
I wanted to do the same thing. I also wanted to use other parts of Django with WebDAV, so I started the django-webdav project.
http://code.google.com/p/django-webdav/
At this point it is working (passes litmus basic + movecopy tests) and I can use it with Windows and Linux (DAVfs2).
Check it out and help out if you think it suits your needs.
for one of my applications I'd like to provide a minimal web interface. This core application is written in C++ and uses Qt4 as a framework. Since I'm also using some libraries I wrote to calculate some things and do some complex data management, I'd like to use this existing code as a backend to the web interface.
Idea 1: Using an embedded web server
The first thing I tried (and which worked to some degree) was using an embedded web server (mongoose). As you can imagine, it is just a very thin library and you have to implement a lot of things yourself (like session management, cookies, etc.).
Idea 2: Using a normal web server and adding a fcgi/cgi/scgi backend to my application
The next thing that came to my head was using a mature but compact web server (for instance, lighttpd) and simple provide a fcgi/scgi/cgi backend to it. I could write the web application using a good framework, like Pylons, PHP, or RoR, (...) and simply have an URL prefix, like /a/... which allows me to directly talk to the backend.
I tried to implement the libfcgi into my application, but it looks messier than needed (for instance you'd have to implement your own TCP/IP sockets to pass on data between your app and the web server and tunnel it through the FCGI library, meh)
Idea 3: Creating a command line version of my application which does the most basic things and use a normal web server and framework to do the rest
This is the third idea that came to my head. It is basically about creating a web application using a traditional way (PHP, RoR, etc.) and using a command line version of my application to process data and return it when needed.
I've got some experience with creating web applications, but I never had to do something like this, so I'd like to hear some ideas or suggestions. I'd like to use JavaScript on the browsers (AJAX, that is) and pass some JSON constructs between web browser and server to make the user experience a bit smoother.
So what are your suggestions, ideas on this? I don't want to re-invent the wheel, honestly.
I would never expose a custom written application to the net as front-end, for that servers like apache or lighthttp are build. They give you some serious security out of the box.
As for interaction of your app with that webserver, it depends a bit on the load and what kind of experience you have with writing software in PHP, python or other languages supported by your web server (via interpreter of course).
A slight load, and a command line tool accessed from PHP might do perfectly well.
A more heavy load and you might wish to implement a simple (SOAP?) server with Qt and access that from a python (or php) script.
That way you don't need to do layout in you app, and you also don't need to implement security all that much.
I'm currently researching a similar situation (custom web app backend using Qt), and the least bad option is FastCGI. Found something you might be interested in. Not production ready without some serious testing, but this might be a good starting point for Qt - FastCGI interop: FastCGIQt
I've used the FastCGI Protocol Driver library for a similar project (also a Qt application), the download link is at the end of that page [Libfastcgi]. Integration with the application turned out actually comparatively easy. Lighttpd + mod_fastcgi was used as web server. Can't say anything about FastCGIQt, though.
You Wt works well to provide a web interface to Qt based applications. Both have a similar programming style, and there's an example that demonstrates the integration with Qt.
Here is example of embedded QML-server: https://github.com/ncp1402/ql-server
We're looking at developing a Web Service to function as a basis for a browser display/gui for a networked security prototype written in C++. My experience with web services has been limited to Java. I prefer Web Services in Java because it's on the "beaten path".
One sure was to do this would be to simply code a Java client which invokes the web service, and call it as a command line with parameters from the C++ code.
It's not ideal, since generally speaking an API is preferable, but in this case it would work and be a pretty safe solution.
A resource which does handles web service development in C++ is called gSOAP, at this url: http://gsoap2.sourceforge.net
Any thought on which is a better approach? Has anyone used gSOAP, and if so, what did you think?
I'd done things with gSOAP, it's not awful. I'm increasingly opposed to the RPC model for web services, though; it forces you into a lot of connection and session state that adds complexity. A REST interface is simpler and more robust.
To me is Axis C++.
For RPC style, have a look at Thrift,
I found it quite better ( faster, clearer, a lot of languages implementations) than soap.
My colleague ended up using a combination of Axis2 / java (for the service) and gsoap for the client. He created the wsdl from the Java service by generating it from a C++ header (using c2wsdl (?) or something like that. He said it was better than using a Java interface because that generated two sets of wsdl, for seperate versions of soap.
Then he used wsdl2java to generate the webservice and a test web client. Once we got that working, he used gsoap to create the web client (in C++), and it worked fine.
thanks for all the answers! I ended using a combination of them.
I had very good experience with gsoap - very simple, performance is good.
If it is acceptable to run only on Windows, there is a brand-new API for that purpose: WWSAPI
Instead of calling the java client from the command line, you can create a java virtual machine inside your C app, instantiate the class and call any methods. This is what the java.exe app does and I think the source code is included in the jdk.
Depends on how low level you want to go. You might checkout yield.