I have a SharePoint server running on my network and I am trying to build an app in Delphi which allows me to access the various SharePoint Web Services hosted there.
Running my app on the same network as the SharePoint server works fine, however, when I attempt to run it on a VM which is not part of the same Domain I can't get authenticated. I was looking for some advice as to how I should be handling authentication for this type of scenario, more specifically, should I be prompting the user for their credentials or is there some built in security model I can use for this?
Ideally I would like to try avoid dealing with Usernames & Passwords in my app and let the OS handle that sort of thing, however, at the moment I can't seem to see any other way around this.
After some investigation, for my particular scenario I decided that the best approach would be to use WinINet. I chose this approach over Indy because after some thorough investigation I found Indy did have some bugs & also it didn't have all the authentication handling we needed built in.
WinINet supports prompting for credentials & automatically authenticating across the wire. See Handling Authentication.
Related
I have developed a REST web service using JAX-RS, hosted on Apache Tomcat server. I used Eclipse for developing this and hosted on a Windows 7 Enterprise machine. Now I need to provide Kerberos Authentication to access my service from any client (for example SoapUI). I have tried to get information from many sites but, all I get is configurations on linux machines.
I'm a newbie to the security concepts and authentication mechanisms and architectures, I would appreciate a good detailed explanation.
Here is a good description of how to integrate Tomcat with Windows authentication:
https://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
Please note that there might be 2 separate things you might want, I'm not sure which one you are looking for.
Authenticate transparently with the Kerberos tickets the user already has.
Authenticate with username+password always, using MS AD to check them.
The first is always transparent, meaning the user does not have to enter username+password again. In the second one she obviously has to.
If you are looking for other services (like SoapUI) to access your services with Kerberos tickets, then those services would need to get a ticket themselves. If you just want those services to use username+password (instead of Kerberos), then you don't need a ticket of course.
Edit after clarification: Using username+password from a windows domain actually does not involve Kerberos at all. It is using LDAP to authenticate, which maps to JNDI in Java. There is a JNDIRealm in Tomcat to set it up, described here:
https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html#JNDIRealm
I have a Delphi application, that needs to send a generated PDF file by email to one recepient of a predefined list of recepients.
I do not want to mess around with MAPI (not all customers have configured this)
I do not want my customers to enter their mail account details (this means SMTP is no option either)
Therefore I consider to use / setup a PAAS web service to receive the email text, the pdf file and the index number of the recepient to actually do the work.
My question is: Does an out-of-the-box solution exist to do this in Delphi, or what would be a preferable way?
For instance I considered using Google App Engine but there seems to be no builtin support in Delphi. I would prefer an out of the box solution or a tested solution with decent documentation. The server part should be as simple as possible.
Edited: Some clarifications:
The resulting exe is installed at the customer computer. I think setting up an extra mail account therefore is no option, because someone could extract the credentials from the exe and abuse the mail account. The same seems to be true for web services that provide only one (login/password) access.
Using OAuth2 seems to be no option either because I do want to send the email without user interaction.
If credentials need to be saved in the executable, and the existing answers suggest so, they should at least provide only very limited rights.
Is this solveable at all?
Is this solveable at all?
No.
If you require that neither the user (by filling in a login form, as is the case with OAuth 2.0) nor the program (by providing hard-coded credentials) authenticates with the web service, the communication with the web service can not be secure.
I suggest to re-think the security requirements and make them much clearer in your question.
To send mail you can use a webservice like http://www.mailgun.com/ or http://aws.amazon.com/ses/
They provide you with a http(s)-api that you can use to send email messages.
You can use Google App Engine with some programming in Python, PHP, Go or Java:
define a HTTPS address where your GAE application listens for POST requests
POST the PDF and the Email text with TIdHTTP
receive the PDF amd theEmail text in the GAE HTTPS server and forward it to the recipient
Here is an excerpt of a Python example for Google App Engine which handles a POST request
class Guestbook(webapp2.RequestHandler):
def post(self):
self.response.write('<html><body>You wrote:<pre>')
self.response.write(cgi.escape(self.request.get('content')))
self.response.write('</pre></body></html>')
Regarding OAuth: GAE supports OAuth but it is not required.
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
I'm currently building an oAuth2 server so that external clients/devices can access data from my service without having to send over user credentials with every request. I've finally grasped how oAuth works after spending an entire day reading numerous tutorials and online documentation, however, there's still one thing that I'm rather unsure of...
When sending a request for an authorization code to an oAuth server, how should I deal with a callback to mobile devices and devices that aren't a webserver?
E.g. this request to my oAuth server will send an authorization code as a callback to a specified webserver (http://client-url.com in this case)
http://mydomainname/oauth2/?client_id=test&grant_type=authorization_code&client_details=test&redirect_uri=http://client-url.com&response_type=code
The server at http://client-url.com will receive a response containing an authorization code and the developer will be able to store a user's oAuth credentials accordingly.
Obviously a mobile device isn't a webserver, so is there a standardised way of dealing with this? I've read online that you can define something called a custom URI scheme within iOS and Android apps. But what about the other mobile platforms out there? And desktop apps? I want my API to be accessible from as many platforms and devices as possible.
The reason why I'm asking this question is because I want to add validation to my oAuth server so that users can only register apps with valid callback URL's. I wasn't sure if should allow any other type of input as a callback apart from a valid URL.
Can anyone shine any light on this? I want to avoid spending hours validating and testing this across all devices as I'm sure anyone that has developed for multiple mobile platforms in the past must have some knowledge about this.
Thanks in advance.
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)