Service Bus for Windows Server SAS authentication over http - authentication

I have a question about client authentication on Windows Service Bus for Windows Server using the REST API. For my solution the clients need to communicate with the Service Bus Queues over HTTP and I can not use Windows Integrated Security. That leaves me with SAS. I have looked at the Microsoft Page where Authentication is described for Service Bus 1.1 but can't figure out how the client can acquire the access token. I know that you can acquire the token calling the STS using the Microsoft.ServiceBus.TokenProvider but that is not an option for my clients. So is there a way to acquire a token providing an access key and name over http to the Service Bus?
Many thanks

There is a sample (linked below) that shows how you can create your own token. With SAS you do not need a service to issue tokens, and can pre-create and distribute them to clients:
http://code.msdn.microsoft.com/windowsazure/Shared-Access-Signature-0a88adf8/sourcecode?fileId=81470&pathId=1811741783

Related

Possible scenario with Thinktecture Identity Server?

I have an ASP.NET SPA which is data driven by Web Api. It's using default login mechanisms at the moment. A future scenario is to do all communication from the web server to the backend over a queue (RabbitMQ).
Then the simplified structure would looks like this:
User logs on, data exchange is routed over the queue to a backend service. My question is now how make the backend aware if the requst is comming from an authenticated user?
I found the Thinktecture STS and for what I know at the moment it looks very interesting. At least the web authentication should be no issue. but for now it looks to me as there is always a browser or a WCF service needed to do the authentication by the examples shown. There are no plans to use WCF or Azure on our site.
Is it possible to transfer tokens the STS issued over a queue and let the consuming windows service be aware of what to do with these token?
You could do poor man's delegation:
http://www.cloudidentity.com/blog/2013/01/09/using-the-jwt-handler-for-implementing-poor-man-s-delegation-actas/
The other thing you can do is use WS-Trust in IdentityServer to get a delegation token for the backend service.

Can the WSO API Manager proxy a web service that is on the app server and authenticated using the identity server?

I have several web services that I want to make available to clients. My clients are split into two groups:
users using a web browser (I serve a web page that uses javascript + AJAX to request data from the web services)
applications (e.g. server app pulling data into a client's system)
1) I can solve the former by exposing my web services to external users using the application server and I can use the identity server to authenticate access (haven't worked how to do this out yet).
2) The latter is nicely satisfied by using the API manager. I can happily tell clients to log in to the API manager and subscribe to APIs. The APIs I create are proxies for the web services mentioned in 1).
I know that an API I create in the API manager can include a username and password for accessing the proxied web service. Is it possible to let an API proxy a web service that is authenticated using the identity manager? Sorry I'm reading documentation and struggling to understand if I can do this. Thanks
". Is it possible to let an API proxy a web service that is
authenticated using the identity manager? "
Currently APIManager supports the service endpoints which are secured using basicauth/usernametoken.
If you use identityserver to secure you service, using any other mechanism, that wont be supported by APIManager.
Stodge,
Default API manager authentication mechanism is Oauth. it uses Oauth token mechanism to authenticate all APIs.
Please refer [1],
Here the authentication component also sits in the AM. This can be delegated to a different AM instance if required.
Hope this helps.
[1] http://docs.wso2.org/wiki/display/AM140/Token+APIs

Secure connection between Windows 8 App and WCF rest service

I've got a WCF service hosted on Windows Azure and a Windows 8 app that currently consumes data from the rest based WCF service.
The service is hosted at abc.cloudapp.net and although currently anybody can access it, I'd like to limit access to users of my app only.
I can't ask users to enter a username and password and I also can't store encryption data in the app as I can't be sure that my Windows 8 App will be obfuscated.
SSL seems to be the only way to go - however the setup of the SSL certificate requires a CSR which I don't believe can be applied to a service hosted on azure.
I'm looking for a step by step guide to securing communication between the app and the service as well as preventing unauthorised access.
Thanks!
REST service works with the HTTP standards. SSL is default mechanism to ensure data transfer with security. Authentication is an implementation question.
Two links to help you with development:
SSL on Azure
REST based authentication
Regards.

How do I authenticate to a WCF service via ACS integration with Windows Live ID?

I have a WCF service that uses UserName authentication via ACS. This works great when I'm using Service Identities but when I try to use my Windows Live ID credentials I get the following error:
System.ServiceModel.FaultException: ACS10002: An error occurred while processing the SOAP body. ACS50012: Authentication failed. ACS50026: Principal with name 'louis#arsunica.com' is not a known principal.
Unfortunately I've yet to find an example of how one uses Windows Live ID with a WCF service. The only examples I could find seem to be focused on integrating multiple identity providers with ASP.NET or MVC websites.
Any help in this regard would be greatly appreciated....
ACS won't authenticate your Live ID username and password directly. ACS acts as a federation provider for Live ID, it's a go-between, so it will only consume tokens issued by Windows Live ID. ACS supports Live ID authentication out of the box in passive (browser redirect) based scenarios but for a WCF service you might consider using Live Connect APIs instead.
To use LiveID with your service, your client first authenticates itself to LiveID, and then presents a LiveID-issued token to your WCF service. Brace yourself though, there would be some hoops to jump through to set all of this up.
To use the Live Connect APIs, you would register your WCF service as an application with Live ID. Clients that consume your WCF service would then need to be capable of handling the web based login page and user consent pages that Live ID will prompt. The docs below are a good start
http://msdn.microsoft.com/en-us/library/hh243641.aspx
http://msdn.microsoft.com/en-us/library/hh243647.aspx
http://msdn.microsoft.com/en-us/library/windows/apps/hh465098.aspx
The next problem is the token you'll get from Live Connect will be in JWT (JSON Web Token) format. I'm not sure if you can request a different token format from live connect, but if your WCF service authentication is WIF based, it most likely expects SAML tokens. JWT is a rather new token format that WIF doesn't yet support so you would have to configure a WIF SecurityTokenHandler on your service that understands JWT tokens. The third link above has some code for reading JWTs, which is a start at least.

wcf and windows authentication

I like to use wcf (windows communication foundation) with windows authentication.
Do I need Active directory for this purpose?
How the server knows about the identity of the client?
If someone can found out the pass of the client that is using the wcf services, can he create the same user name on different computer and use the password to access the wcf services ?
Yes, if you want to use Windows authentication, you need Active Directory as the source where the user gets validated.
The way this happens is by means of a user "token" - when your client logs into his PC with his Windows credentials, the login process will check with AD whether the user is legit and issue a "token". This token is then used in calls to a WCF service to determine who it is that is calling the service.