I was studying about the SASL Anonymous mechanism in xmpp.
What I found was the XEP-0175 for best practices to use XEP-0175.
The SASL Anonymous authentication mechanism allocates you a UUID based jid and then allows you access to the server.
Suppose there are two users Alice and Bob.
Alice authenticates via SASL Anonymous and is assigned temporary jid
Bob authenticates via SASL Anonymous and is assigned temporary jid
How does Alice come to know about Bob's jid and Bob comes to know of Alice's jid?
In essence how is communication established between the two?
Users are anonymous, that's the purpose of SASL anonymous. So, this is not to use for long running, persistent relation with other users.
The use case for Anonymous authentication is not the whole scope of the XMPP usage but is more limited.
It is useful for example to receive events, for example coming from a pubsub channel, over a short period of time, on a web page.
It can be also used to grant access to chat rooms without the need to create an XMPP account.
Another example, is that one of your user may invite another one by email for a short-lived one time conversation.
Related
I want to have custom permissions for different channels for security purposes. In the documentation and examples, shortlived tokens are used. I don't want to spam the auth server every minute and don't want attackers being able to spam until their token is revoked. pubnub grants are very simple and work well. Does ably have a similar feature for access management?
According to the documentation it seems impossible:
There are also usecases where the server would want to instruct the client to re-authorize, for example to revoke some permission. There's no special mechanism for this; you can use whatever mechanism you normally use to communicate with the client to tell it to call authorize(), such as a message sent over an Ably channel that the client is listening on. If all else fails, you can wait until the token expires, at which point the client will be forced to seek a new token from your auth server. (You can specify how long the token is valid for at creation time; the default is one hour).
Source: https://support.ably.com/support/solutions/articles/3000056545-recommendations-for-incrementally-authorising-new-capabilities
I might not be understanding the question fully but Ably does have the ability to give granular permissions on a per channel level. It works by granting capabilities to an API key and scoping the API key to a channel, more info in the FAQ.
So you could:
Create an API key named Channel A Pub with only publish capabilities to channel A.
Create an API key named Channel A Sub with only subscribe capabilities to channel A.
Create an API key named Channel B Pub+Sub with both publish & subscribe capabilities to channel B.
This does require your application to use multiple API keys and create multiple Realtime/REST instances for each of them.
Creation of API keys can be done at runtime now there since the Control API has been made available. That allows for creation of apps, keys, queues, and integration rules.
In addition there is a token revocation API that can be used to revoke API keys.
Ably now has a token revocation API.
https://ably.com/docs/core-features/authentication#token-revocation
I am designing the authentication system for a piece of software and need some guidance on how SASL and Kerberos services interact.
Here is the situation:
I have a client/server application that is itself pretty standard: only registered users can use perform actions. As an MVP I would typically implement a pretty standard solution:
Database stores username + salted hash of passord
Authentication attempt from client over HTTP includes username/password over TLS
Backend checks that username/password are valid and returns a bearer token that can be used for the duration of the session
In this case, however, there is a complicating factor. Some users of our system use Kerberos internally for user authentication for all internal services. As a feature, we would like to integrate our software with Kerberos so that they don't have to manage an additional set of users.
A more senior engineer recommended I look into SASL so that we might support several auth protocols simultaneously; standard customers can authenticate their users with the PLAIN method (over TLS), for instance, while other customers could limit authentication to only the GSSAPI method.
Up to this point, I have a clear idea of how things might be set up to achieve the desired goals. However, there is one more complicating factor. Some of the customers that want our system's auth to support Kerberos have other resources that our system will rely on (like HDFS) that also require authentication with Kerberos.
My understanding of Kerberos is this:
A client authenticates with Kerberos's ticket granting server
Upon successful authentication a TGT is returned that can be used for any future interaction with any Kerberos service in the system
Now to the point: How can I make all of these technologies work in harmony? What I want is:
- Client logs into my server
- My server authenticates client using customer's Kerberos system
- Client is given the OK
- Client asks for something from my server
- My server needs access to customer's HDFS, which requires Kerberos auth
- Server authenticates without asking the client to authenticate again
One possible solution I see to this is the following:
Make my server itself a Kerberos user
When the server needs to perform an action on HDFS, have it authenticate using its own credentials
There is a big downside to this, though: pretend the customer's Kerberos system has two realms: one with access to HDFS and one without. If users of both reals are allowed to use my system, but only one set can use HDFS, then I will need my own logic (and potentially objects in a DB) to determine who can perform actions that will require access to HDFS and who cannot.
Any pointers are going to be super helpful; in case it isn't obvious, I am quite new to all of this.
Thanks in advance!
It's not clear exactly what your question(s) are, but I'll do my best to address everything I think you're asking.
Firstly, I just want to clear this up:
Upon successful authentication a TGT is returned that can be used for
any future interaction with any Kerberos service in the system
That's not quite correct. The TGT enables the user to request service
tickets from the KDC for specific services. The service ticket is what
gives the user access to a specific service. The TGT is used to prove the
user's identity to the KDC when requesting a service ticket.
Client asks for something from my server - My server needs access to
customer's HDFS, which requires Kerberos auth - Server authenticates
without asking the client to authenticate again
This is a common enough problem and the Kerberos solution is called delegation. You should try to use Kerberos delegation in preference to coming up with your own solution. That said, how well supported it is depends on the technology stack you're using.
There are 2 kinds of delegation supported by Kerberos. The first kind is just called "delegation" and it works by sending the user's TGT to the service along with the service ticket. The service can then use the TGT to get new service tickets from the KDC on behalf of the user. The disadvantage of this approach is that once a service gets a user's TGT, it can effectively impersonate that user to any service that the user would be able to access. You might not want the service to have that level of freedom.
The second kind of delegation is called constrained delegation (also known as services4user or S4U). With this approach, the client doesn't send it's TGT to the service, but the service is allowed to ask the KDC for a service ticket to impersonate the user anyway. The services that can do this have to be whitelisted on the KDC, along with the services that they can request tickets for. This ultimately makes for a more secure approach because the service can't impersonate that user to just any service.
A more senior engineer recommended I look into SASL so that we might
support several auth protocols simultaneously; standard customers can
authenticate their users with the PLAIN method (over TLS), for
instance, while other customers could limit authentication to only the
GSSAPI method
Yes this is a good idea. Specifically, I'd recommend that you use the exact same session authentication mechanism for all users. The only difference for Kerberos users should be the way in which they get a session. You can set up a Kerberos-protected login URL that gets them a session without challenging them for credentials. Any user that hits this URL and doesn't have Kerberos credentials can just be redirected to a login page, which ultimately gets them the same session object (once they log in).
On the back end, the credential checking logic can use SASL to pass Kerberos users through to the KDC, and others through to your local authentication mechanism. This gives you a seamless fallback mechanism for situations when Kerberos doesn't work for the Kerberos users (which can happen easily enough due to things like clock skew etc.)
There is a big downside to this, though: pretend the customer's
Kerberos system has two realms: one with access to HDFS and one
without. If users of both reals are allowed to use my system, but only
one set can use HDFS, then I will need my own logic (and potentially
objects in a DB) to determine who can perform actions that will
require access to HDFS and who cannot.
This kind of thing is exactly the reason that you should use Kerberos delegation instead of coming up with your own custom solution. With Kerberos delegation, the KDC administrator control who can access what. If your service tries to impersonate a user to HDFS, and they are not allowed to access it, that authentication step will just fail and everything will be ok.
If you try to shadow the KDC's authorization rules in your own application, sooner or later they'll get out of sync and bad things will happen.
I have a service that sends identification information through SIP INVITE requests, such as a user's username in the FROM header field. I would like to know if these is anyone to prevent an attacker, who already has access to my server, to create their own INVITE and send it to another user pretending to be another user in the network. Thank you and have a great one.
An attacker doesn't need access to your server to send an INVITE request in your user's name. He can do that from anywhere in the network. This is where authentication comes in. The recipient (UAS) can challenge the request, forcing the attacker to resend the request with authentication information, such as (hashed) passwords.
Of course this mechanism relies on the attacker not having the username/password combinations. This could prove a problem if he already has access to your server. But I think you might have bigger problems in that case.
If you have multiple RESTful web services running on different subdomains (accounts.site.com, training.site.com, etc) what is a good authentication mechanism when one service needs to consume another?
Human authentication is easy because they supply their login credentials and get back a JSON Web Token which is then sent with every request to authenticate them.
A machine having a username and password just seems odd so I was wondering what are some proven ways of solving this problem?
It depends on... From the service perspective the other service is just a REST client, so let's stick with these terms.
If you want access different user accounts with your REST client, then you must register your client by the service and you will get an API key. The user can give privileges to that API key, so you can do things in the name of the service users if they allow it.
On the other hand if your client wants to access only its own account, then it is just a regular user of the service and it can have username and password just like the other users.
I have created two facebook test accounts for my test application. Both test accounts have xmpp_login extended permissions. I am using SleekXMPP python library to connect (with second account) to the chat.facebook.com server. At the Resource Request phase (iq type="set" id="somethinghere" bind xmlns="urn:ietf:params:xml:ns:xmpp-bind" iq) I will get JID of the first test account as a final JID as a response from the server, while I am trying to use the second account JID.
Is there some way to tell at iq stanza request phase to the chat server, that I am requesting some specific test account jid for my client (In the developers.facebook.com chat API example the options['uid'] is not used for anything) ? I would like to create few python clients with test accounts to my application which are communicating with actual browser users through chat.
Thanks a lot for help,
-Mika
Are you using the the X-FACEBOOK-PLATFORM authentication method? I.e., using:
self.credentials['api_key'] = '... API_KEY ...'
self.credentials['access_token'] = '... TOKEN ...'
If so, Facebook provides the JID during binding based on the provided access token; there isn't a way to request a different one, and the initial JID provided when connecting is ignored. Are you certain that you're using different tokens for your accounts, and that it is the correct access token being used for your second account?
In the API documentation you mentioned, the options['uid'] is simply referring to the user's JID, in the form the_username#chat.facebook.com.
If you're just using the DIGEST-MD5 authentication option (i.e, not setting the credentials as above) then it's not clear where the issue is. Don't forget that you can join the sleek#conference.jabber.org room for help debugging with Sleek in that case.
-- Lance