My newest task is going to be to implement automatic update of a licence:
The program detects that the licence is expired or about to expire and offers the user to automatically upate this. So far so good. Now what is needed:
The program sends the user's credentials to a win 2008 server over the internet.
The server checks the credentials and if they are OK generates a licence file that is sent back.
How to implement these steps? I consider using WCF, with which I have some experience.
The transfer mechanism isn't the issue. WCF should work fine. You could use SSL and/or WCF Security.
The inherent security of the credentials and license is the concern. Remember, anyone can call the service and former clients have access to expired license files. People may try to cheat the system. Ask yourself questions such as:
Can person A figure out what person B's credentials are and request a license as person B?
Can a person reverse-engineer a license file and extend its life?
See for instance Need advice to design 'crack-proof' software (and numerous other SO posts on licensing).
Related
Since there are a lot of APIs for Skype for Business, and the documentation isn't always very clear, and many hours have already been wasted developing for an wrong API, here I am asking you:
I am looking for an API which enables me to administrate multiple Skype for Business Online users. Required Features:
Skype for Business Online compatible
Read and Set Presence from other users
Set Call Forwarding for other users
And all that without knowing the user's passwords.
I already started developing for UCWA until I realized every user's password is needed for setting the presence.
I am aware of the capabilities of an UCMA Trusted Application, but unfortunately S4B Online compatibility is required. Maybe it's possible to make it compatible with an interface?
Every thought on this is much appreciated.
This would have been possible with on premise Skype for Business:
A trusted UCMA application to read and set presence
Automating SEFAUtil to set the call forwarding options (which relies on UCMA)
Unfortunately (as you rightly said), neither of these are supported against Online, as there is no direct replacement for UCMA. There's unlikely to be a replacement in the future as Microsoft are pushing to move customers away from SfB and on to Teams.
Depending on exactly how you need this to work, one option would be to use the Lync 2013 client SDK, which still works against the SfB client (but is now out of mainstream support). You'd need to create a "hidden" application that gets deployed to the users desktops, and sends and receives commands to/from your centralised administration app. In that way, you'd be able to send commands to the user's application, which would then automate the client into setting presence and changing call forwarding. Some obvious downsides, though:
A lot of work to build out the client/server applications and manage the connections between them
Would only work when the user is signed in to their client (as the Client SDK uses the running instance of the Skype client)
Depends on being able to deploy to a client machine
Not an ideal solution, I know, but with Teams replacing SfB Online (over time), your options are going to be limited!
We are bringing on a new temporary developer to help out with a project and I've been asked about installing libraries to store the SMTP login credentials to our dontreply#xyz.com email so that the developer can set up web forms without access to the credentials as this would require us to change the credentials for all out forms after the developer finishes her contract.
I've searched and found nothing, the closest thing was someone stating that you should create a company account instead of using personal account on this post: PHPMailer Hide SMTP Authentication?
can anyone help with me with this or point me in the right direction at least?
Thanks
Like that question says, there's not much you can do to prevent the dev getting hold of the credentials. Even OAuth won't help. This isn't a PHPMailer question, or even a PHP question really - it's about configuration management, and the same problems occur in pretty much all languages.
It may be solveable at a different level though - One option might be to wall off direct access using a mail proxy / relay. Configure a nearby/local mail server that you can submit to freely, and have that deal with real outbound, including relaying through your mail account. That way the developer can send through your chosen server without needing any direct access at all. It might make their life a little more difficult, but it solves your main problem.
In the context of WCF/Web Services/WS-Trust federated security, what are the generally accepted ways to authenticate an application, rather than a user? From what I gather, it seems like certificate authentication would be the way to go, IE generate a certificate specifically for the application. Am I on the right track here? Are there other alternatives to consider?
What you are trying to do is solve the general Digital Rights Management problem, which is an unsolved problem at the moment.
There are a whole host of options for remote attestation that involve trying to hide secrets of some sort (traditional secret keys, or semi-secret behavioural characteristics).
Some simple examples that might deter casual users of your API from working around it:
Include &officialclient=yes in the request
Include &appkey=<some big random key> in the request
Store a secret with the app and use a simple challenge/response: send a random nonce to the app and the app returns HMAC(secret,nonce))
In general however the 'defenders advantage' is quite small - however much effort you put in to try and authenticate that the bit of software talking to you is in fact your software, it isn't going to take your attacker/user much more effort to emulate it. (To break the third example I gave, you don't even need to reverse engineer the official client - the user can just hook up the official client to answer the challenges their own client receives.)
The more robust avenue you can pursue is licencing / legal options. A famous example would be Twitter, who prevent you from knocking up any old client through their API licence terms and conditions - if you created your own (popular) client that pretended to the Twitter API to be the official Twitter client, the assumption is their lawyers would come a-knocking.
If the application is under your control (e.g. your server) then by all means use a certificate.
If this is an application under a user control (desktop) then there is no real way to authenticate the app in a strong way. Even if you use certificate a user can extract it and send messages outside the context of that application.
If this is not a critical secure system you could do something good enough like embedding the certificate inside the application resources. But remember once the application is physically on the user machine every secret inside it can sooner or later be revealed.
What are the best practices if I want my application to authenticate itself to other services?
Let's say I want my application (the programming language doesn't matter) to access a file share or a repository but I don't want to ask the user for password. In addition, I don't want to store passwords in the code of my application. What else can I do? Till now I found only 2,5 options:
1.use Integrated Windows Authentication - but this will, obviously, work on windows only
2.use client certificates and let the service verify them before allowing access
3.use LDAP/RADIUS/CAS with client certificates
is there something else?
There is always good old Kerberos. A little old and stuffy but probably a very interesting contender for what you are trying to do.
I'm currently thinking how I could protect my REST API which is used only by my mobile application from being used by other applications?
Could a API-Key be a good solution, because just me know the secret API key.
Is there a better solution?
Leon, you keep mentioning "someone else using my API with another application". So, you want to tie your API to be used only by one application? So, you don't want to give access rights to a user, you want to give them instead to an instance of your application running on the user's mobile device.
In essence: You don't trust the user!
Well, in that case you need to make sure your application is closed source, need to code your credentials into your application in such a way that nobody can retrieve them or store the credentials for it in a specially encrypted manner on the device, the decryption key for it being readable only by your application. In a way, you need to implement a form of DRM to prevent people from doing stuff with data on their mobile device. And you need to hope that nobody can reverse engineer it.
If your app becomes popular / interesting enough, count on the fact that people who are very, very good at this sort of thing will look at your application and will break your encryption before you know it. Maybe, if you put the same amount of effort into it as Skype has, maybe then you can ward them off for a while.
But ask yourself: Why bother? Why don't I trust my users? Is it really worth it to jump through hoops like this to prevent some other application from using my API?
Just lead your user through a registration process in which each app instance gets a unique key from the server (or a unique HTTP auth password) and stores that somewhere on the user's mobile device. Then, to access the interesting features in the API, require the presence of this key/password. But don't go through extreme length to obfuscate or encrypt the key when you store it locally, it's not worth it. If you every detect misuse later, you can always revoke the access rights for a particular account on the server anyway.
Use HTTP Authentication. REST is all about using the facilities available in HTTP, so the native HTTP auth should be used. With basic authentication you’ll have to use HTTPS though. If you cannot do that use HTTP digest auth or NTLM.
All of them have different strengths and weaknesses, and not every one of them might be supported by your HTTP server and client library.