I have setup Trusted Application for Skype for Business in the azure
portal.
I am able to start a conversation using UCWA API and
send/receive message.
I am adding the trusted application end-point
in Skype For Business client contact and it is getting added as a
contact in my S4B client as well, but it's presence is shown as
unknown.
When I send a message from S4B client to the trusted
application end point I am getting the error in the chat windows as
"We couldn't reach demosfb to send this message"
My question is
Is it possible to start a conversation with a trusted application end-point as we do with a normal contact from Skype For Business client?
This scenario is not supported yet.
There is support for calling into the PSTN number associated with the application trusted end point.
Related
I've been breaking my head over how to do this, as it doesn't seem to fit any example I could find online.
My IOT device servers will run on the client network and may be accessed over it or over the open internet (with port forwarding). the device comes with a paper-printed initial pass like a router.
the client is running a mobile app.
As I hate planned obsolescence (ie, the device should keep working even if the company shuts down), I don't want to create a dependence on any third-party auth service, so the server and the app should just establish trust between themselves.
with the initial contact assumed to be trusted.
In all the examples for gPRC auth I could find, the client should somehow have ahead of time the server public key. but as there are many devices, and I want each one to have a unique cert, I don't see how I can ship the app preloaded for the specific device the user will get.
I have come up with the following:
the device generates private/public key
an insecure grpc channel serves the public key to the client
the secure grpc channel is established with that key
the client authenticates with the initial password to use the API over the secure channel
client changes the password
I'm not looking for super-max security, just basic common-sense security.
the main issue I have with the typical scheme where SSL is used to authenticate vs a domain is that I don't know via what domain/address the device would be accessed.
are there any glaring problems in the scheme? or any reason it would not work?
Thanks!
We have some Hosted Windows Services using net core (3.1 and later) and a self signed Certificates that we ship to customers.
These Services run on local servers and are listening on localhost:someports and have mostly rest Apis so the certificates are no problem on that side because we can validate them via code.
But some of them will get customer facing Status Frontend Uis where the browser will show the big "self signed certificate is bad" message which the user has to accept and don't look that nice overall.
So is it possible to use a "real" certificate for such services to use https without that hassle?
I have the Sonos Acme developer test service setup and running but my Sonos Player doesn't seem to be able to connect. I'm wondering if a TLS SSL certificate is required no matter what even in a sandboxed environment.
I'm running the java service on a remote AWS instance behind a domain. The service is setup with the default installation details. It does not log any sort of connection attempt once I add the service to the Sonos player via customSD.
Accessing the Sonos Player via customSD and adding the Acme service does respond with Success! But again it doesn't show up in the service list. Manually pulling the WSDL does work correctly via the http request.
Also to note that Sonos seems to be in the middle of creating it's new developer portal and since last Monday ( June 24th ) the new portal no longer references the Acme test service. I'm wondering if this is due to it no longer being valid and it's documentation out of date (est. 2017-2018).
I expect the service to show up in the Sonos Controller when adding a new service but it doesn't appear and the log doesn't show any attempts to connect.
An SSL endpoint is required for production, but you can use a non-SSL endpoint for testing. See the comments in this answer for details: With a Sonos player, adding local service to customSD does not show up Music Services
I am working on a small service accessed from a client on Windows Phone 8 and/or WinRT device that requires a moderate amount of security. My goal is to create a service that runs in Windows Azure.
My application requires authentication that verifies two things:
1) Authenticity of the client
2) User credentials of the client
Step 1) I need be certain to a fair degree that the application calling the service is, in fact, my client application.
Step 2) The user needs to have an account in the system that can be authenticated. I can implement the authentication by simply making a Login() method in the interface (unless there is a better way). However, for this, the communication between the client and the server needs to be secure as I do not want my username+password combo unencrypted.
My current view is that implementing it as a WCF service would probably be the way to go as I might have further interest into porting to other platforms on the client-side and a quick look showed me that this is somewhat supported.
However, as I am new to all these certificate shenanigans, my question is whether I can use self-signed certificates for securing my connection? Only my server and my client need to be able to verify the authenticity. Furthermore, any pointers to exactly how this is done in the WP8 + Windows Azure case?
Another deal is that assuming that a nifty hacker breaks open my program from the client hardware, can he take the certificate and use it to create his own client to login with (his) username/password and performing actions performed by my original client? Or is there a way to prevent this on the client side? In other words, can my server be sure of the authenticity of the client software based on having a valid certificate signed by me?
Step 1 is pretty much impossible. No matter what attestation method you use in code it can be duplicated in code by another programme.
Step 2 doesn't require WCF, although you can use it with basic auth. It's just as easy to expose a RESTful service with WebAPI which supports basic auth as well. Securing the communication is the same for either WCF or WebAPI - use SSL.
WCF does not like self signed certificates, and configuring it to use them does away with some of the security, depending on how you do it. Given that SSL certs from trusted CAs start at around $10 it would be a false economy not to get one. Azure webworkers support SSL certs, and support for Azure Web Sites is coming, although with no firm date.
Finally a client certificate in managed code can be reasonably easily extracted, so you cannot rely on it to identify client code.
This is our setup - our customers will have a database server with our database on and multiple clients running our frontend. We have some WCF services to allow the clients to request info from the database and each WCF session is authenticated with a username/password stored (encrypted) in the database. This all works fine and has been in use for a couple of years.
We're now adding the ability to sign in using a USB fingerprint reader attached to client PCs. For this we store each users' fingerprint template in the database and then upload them all to the device. The device can then tell us which user has presented their finger.
What is the best way to securely allow our fingerprint client to authenticate over the WCF service without using the user's password and without opening up the system to attack from unauthorised users?
My first thought is to define a secret key that both client and server know, encrypt it on the client with a timestamp and the logged in user id and send it to the server which can then confirm that the request came from our client.
Is this a good idea? Can an attacker just relay the same message to start an unauthorised session?
I'm not a security expert so I'd prefer an existing solution over rolling my own for obvious reasons.
We're using C# and only targetting Windows.
You could use an x509 certificate stored on the Client to provide the client credentials required for the WCF service. This would work in the same way that server security is provided via SSL certificates.
Some info on working with certificates:
MSDN - Message Security with a Certificate Client
MSDN - Working With Certificates
A word of caution would be that you would obviously have to manage the distribution and validity of certificates.
Th other alternative is to use the clients windows account for authentication purposes if the client machine is on the same domain:
Some info on working with Windows Account:
Message Security with a Windows Client