I want to authenticate all MQTT subscribers on a topic with Solace using Basic Auth . (Username and password) . But want publishers to send to that topic without authentication.
I configured basic auth. and ACL's on a VPN but that wants my both subscribers and publisher to use username/password. Can this be possible via any configuration to allow anyone to publish to a topic in solace but only authenticated users to subscribe and listen on that topic ?
Only one type of authentication is supported per Message VPN on the Solace VMR. It seems your use case requires both a basic authentication type of "None" as well as "Internal" to be supported.
One way to achieve this would be to create two Message VPNs, where the first uses a "None" type of basic authentication and allows anyone to publish a message without requiring a password and the other Message VPN uses an "Internal" type of authentication, where the user has to authenticate using a configured username and password in order to subscribe. You can set up a Message VPN bridge between the two Message VPNs which will permit messages published in one Message VPN to be delivered to the other Message VPN.
For added security, you can configure the ACL profiles in the Message VPN using "None" authentication to disallow all subscribing. This will prevent a subscribing user from connecting directly to this Message VPN without having to authenticate with a username and password.
The problem here is the difference between Authentication and Authorisation.
MQTT authenticates the user at the time the client connects before it subscribes or publishes any messages.
Authorisation to publish/subscribe to topics takes place when that client then tried to either publish or subscribe, and is based on the authenticated user.
Related
i want to use affectiva API, for it I must send token with username and password.
From documentations:
Our APIs use HTTP Basic Access Authentication to authenticate clients. HTTP Basic Authentication relies on a TLS transport to ensure that the client credentials cannot be seen by a third party, so all API communications must be transmitted over a TLS-protected channel. Please ensure that your Index Service API begins with “https” before using it.
But I can't find SIGN UP button how i can receive username and password?
For the moment you will need to contact sales#affectiva.com to get access to EaaS or the Affdex MR products.
I've been using wcf for a while and its authentication mechanisms, Windows, UserName/Password, Client certificate for a while.
I'd like to better understand how WCF uses these authentication mechanisms internally when creating SOAP messages and sending them.
Specifically, are the authentication credentials passed by wcf in every SOAP request, or does it only pass the authentication credentials in the first request and then some kind of token is issued and passed back and forth during subsequent sessions?
Are these authentication credentials (username+password, windows, client certificate) passed in a different manner depending on whether the security mode is transport or message? Is it that in message mode, the authentication credentials are inside the SOAP message, while in the transfer mode, http headers are other transport protocol specific are used to pass the authentication credentials?
Lets just assume that the SOAP message is secured using https when Transport mode is used and encrypted when using Message Mode and not worry about message privacy or tampering for this question.
You've asked several big qeustions, but I'll try to answer the question about sessions.
Session and authentication handling depend on the binding you're using. If you're using basichttpbinding, for instance, the host basically acts like a web server and no persistant "sessions" are created; as a result each SOAP request you send must contain everything necessary for authentication on the host. However, there are some bindings available like WSHTTPBinding that allow for the creation of security and reliability sessions that persist after the initial authentication using a token.
Wrapping the message in SSL should prevent problems.
How to implement authentication security in WCF?
Means if any user is registered, than only be able to use service.
One way:-
Like, a mobile application at the time of installation update unique key with application Database.
So when client tried to connect with WCF service and if the key match then only be able to connect with service.
I want to know is there some other way to prevent unauthorized access for service?
You can read through this link Programming WCF security.
Read this link to Implement CustomUserNamePassword Authentication
You can configure your bindings to perform CustomUsernamePassowrd Authentication where you validated if the username and password are valid and if so you grant access to the service else deny.
I have a web service hosted in IIS 7 that is to be called from a WCF client that runs in a different domain.
Currently, the wsHTTP binding has been configured using default settings. When the call is made the service complains that the client couldn't be authenticated (Message : The request for security token could not be satisfied because authentication failed.). I guess this is because it's trying to use windows authentication and the clients ID cannot be validated against the AD server of the service.
What's the best way to get around this? Can the service be configured to run under the ID of a local account? How best to check the call has come from authorised client? I'd rather avoid certificate generation and management if possible. Ideally, I'd authenticate the client by username / password by then have the service operate under it's own local ID - to gain access to resources on the service server.
Any advise gratefully received.
Thanks
Rob.
You can use user name and password but your service should use certificate if you don't want to send user name and password in plain text. Your option is either:
HTTPS with user name and password in message
Message security with user name and password in message
Both requires certificate.
Here's a good tutorial that I used to do just that.
http://www.codeproject.com/KB/WCF/wcf_https_usernameauth.aspx?msg=3527563#xx3527563xx
I'm writing a set of WCF services that rely on transport security with Windows Authentication using the trusted subsystem model. However, I want to perform authorization based on the original client user that initiated the request (e.g. a user from a website with a username/password). I'm planning to achieve this by adding the original user's credentials in the header before the client sends the message and then the service will use the supplied credentials to authorize the user. So I have a few questions about this implementation:
1) using transport security with windows auth, I do NOT need to worry about again encrypting the passed credentials to ensure the validity... WCF automatically takes care of this - is this correct?
2) how does this implementation prevent a malicious service, running under some windows account within the domain, to send a message tagged with spoofed credentials. for e.g. a malicious service replaces the credentials with an Admin user to do something bad?
Thanks for any help.
What binding are you using? Is this service only within your corporate LAN, or do you plan to go outside the firewall?
To answer your question (as far as I can)
1) With Windows authentication over transport security, the transport layer will be encrypted and safe - no need to worry about additional encryption of credentials etc.
2) It cannot. If a malicious service manages to "hijack" some valid Windows credentials and poses as "John Doe" who has an account on your corporate network, there's no way the WCF service can distinguish this from a valid request by John Doe.