Jabber auto-login with random name - xmpp

I'm building a live chat using JSJaC and ejabberd . It's all working except that all site visitors are given the account 'guest'. If two visitors try to livechat at the same time the responses get muddled or the first user is logged out.
I can randomly set the guest name but then I need to check whether that name is registered or auto-register and hope it hasn't been registered before. I tried assigning each login to a random resource name but this still merged the conversations.
In short i'm looking for the easiest way to allow multiple anonymous logins to start individual conversations with the livechat account. Even better (but optional) if the livechat could round-robin to a different user when the primary livechat account is in a chat.
The solution can be web-client or server based, I don't care since I control both (and ejabberd supports various modules).
BTW, when I try to auto-register a registered account the JSJaC simpleclient demo returns:
An error occured:
Code: 409
Type: cancel
Condition: conflict
I haven't established yet if this is something I can ignore or override with a custom client or server setup. I suppose I could just detect this error and try again without auto-register but I'd like to hear better/easier options.

Try enabling anonymous login mode on your ejabberd server? Then you don't have to register the client accounts, just pick any random username and password and ejabberd should accept them...

I guess you can use external authentication in ejabberd
I'm in the same situation: I want anonymous users to be able to login in the server, but some special users also be able to login for adiminstrative tasks...
So I decided to write a php script as an authentication handler for ejabberd.
Then it will accept all logins with the name starting with anon_*
and authenticate other users against a database.

We had a similar issue in a project - we wanted users to be able to login without requiring any account creation or clashes - auto-registration would not work for us because names could clash. In the end we chose anonymous login with SASL authentication in ejabberd - it allows anonymous login and dynamic account creation and I believe the accounts do not stay on the system (they are alive only whilst the connection is open), however from what I remember the server will generate a random ID for the user.
The GUID JID problem might be able to be solved with the use of Nicknames
Set up SASL
Ejabberd Support Page - SASL

If you can't get ejabberd's anonymous mode working, you might try creating a GUID for each user's base name, and just registering the user on the fly. You'll want to have a periodic script that deletes old unused accounts from the database.

Related

Create MS Teams chats with MS Graph (or PowerShell)

I'm currently trying to use Microsoft Graph to send a Microsoft Teams Chat message to a specific employee.
The idea behind that is that I want to be able to send chat messages using PowerShell, but for now, I'd be happy to get it done in Microsoft Graph first and build a PowerShell script afterward.
Important: I don't want to post a message to a Channel, only in a 1:1 chat.
What I've tried:
I'm able to get the current chats for my own user by using:
https://graph.microsoft.com/beta/users/{myid}/chats
If, however, I try that with a different user's id, I get a 401 (permission denied) error. I can't even see their current chats even though I have all available permissions.
In the error message, it says the following:
"User Id must match the API caller when called in delegated mode"
... but I don't want to use delegated mode since that'd mean I'm executing the commands as if I would be that user, and therefore couldn't create the chat message which I want in the first place.
It might sound rather confusing, so I hope you get what I mean.
To my knowledge, there's no way to send a message directly to the user without some kind of context. The problem becomes, for instance, where would the message appear, and who would it be from?
If you could deal with it being inside a Channel instead, then PowerShell is fine as you can set up a webhook to do this. I've done the same, from PS -> Teams a few years ago, so I assume it should still work. This article should help.
Alternatively, if you really want a "1-1" conversation, so to speak, you need to create and register a Bot, so that the message comes "from someone" to the user. This concept is called Pro-active Messaging and I've posted more about it here. However, coming purely from PowerShell it's going to be a LOT of work:
Create a Bot in Azure to get the App ID and Password. Technically this would be a non-existent Bot as there's no implementation, which means if the user were to reply it would go nowhere. This might be ok? You could possibly try build an Azure Function Bot in PowerShell, but not something I've done myself so can't advise (I've only used C# for Bots thus far)
Create a Conversation ID, and save it for later - again, a bunch of work.
Convert the code (e.g. from my post above) into PowerShell, referencing the relevant NuGet packages.
So, I'd recommend trying to find an approach using a Teams Channel rather, and messaging the user there, if you can manage that in your use case?
Unless all of this is irrelevant if you're trying to send on behalf of another user?
The term "Delegated" in this context refers to the type of permissions claims included in the OAuth token. There are two types; Application and Delegated.
There are two key rules when it comes to Application vs. Delegated scopes:
A single token may only contain a single type of scope. In other words, the token itself is either an Application or Delegated token, never a combination of the two.
The type of scopes applied to a Token is determined by the OAuth Grant you used to obtain it:
Authorization Code: Delegated
Implicit: Delegated
Client Credentials: Application
With regard to the List Chats (/chats) endpoint, only Delegated permissions are supported:
Delegated (work or school account): Chat.Read, Chat.ReadWrite
Delegated (personal Microsoft account): Not supported.
Application: Not supported.
There is a general rule of thumb when it comes to permissions in Microsoft Graph (I use 'general' here since there are a couple of exceptions in older endpoints): Delegated scopes that only apply to the current user end in Read or ReadWrite while those that apply to any user end in .All.
Since these two scopes (Chat.Read and Chat.ReadWrite) do not end in .All, and only Delegated scopes are supported, this tells you that the only Chats you are able to access are those owned by the currently authenticated User. In other words, you cannot read another User's chat messages via the API.
If you think about it, this makes a lot of sense. If you didn't have an authenticated User, who would the Chat message you sent be "from"? A chat message requires both a Sender and a Recipient.
For your scenario, there are a couple of possible workarounds from a Teams ChatBot to simply setting up a new User that you authenticate as and send messages to other Users from.

MembershipReboot change Username, Email, and Reset Password

We are using identityserver3 and membership reboot for authentication in our application.
We now have a requirement to change the UserName Email and Reset Users Passwords form an Admin area in our application. I have seen Identity Manager but that seems to not be what I'm looking for. From reading Membership Reboot Wiki it seems to support everything that I would want to do. I just don't have a clue what the implementation for this would look like.
My thought is that we would call into our API where we know that the user is authenticated and then just call into the MembershipReboot API to take care of the task at hand be it changing UserName or Email or Reset Password.
But like I said I'm not sure. Should we be using Identity Manager middleware? It feels like that isn't the answer as we are writing our own admin interface and from what I could see it is't supporting a password reset via email and the MembershipReboot API says that it does.
Or should we be calling back into our Identity server and making the change? It feels like no because that is for logging into the applications.
Yes, you need to create your own code to allow users to update their demographic info including email and password.
You need to use the UserAccountService -> This code I am using my own CustomUser where I store all the information that would normally be stored in the UserAccount Table
_userAccountService = new UserAccountService<CustomUser>(new CustomUserRepository(new CustomDatabase()));
Then use:
_userAccountService.ChangeEmailRequest();
_userAccountService.ChangeUsername();
_userAccountService.ChangePassword();
If you prefer to have users do this from an email (use when they are not logged in)
_userAccountService.ChangePasswordFromResetKey()
I'm looking at this too but haven't actually implemented it yet. Yes I think you are right that you need to call into the MembershipReboot API yourself. There are methods on the UserAccountService class to perform these functions. See the sample SingleTenantOwinSystemWeb in the MembershipReboot source code.
The IdentityManager functionality is limited but useful for developers to set up users with roles & claims etc for testing, or as a basic Admin tool.

Can you prevent a user logging in multiple times with Janrain, or similar social network logins?

I would like to enable logging in from multiple services on my site, but would not like users to login with, say, facebook and then logout and then back in with, say, Google+.
I am not sure if there is a practical way to detect that someone has done this?
I saw Janrain mentions account linking, is this provide this kind of service?
Security doesn't have to be watertight, but would like to make it hard to login multiple times and post from different accounts. At the same time, having multiple providers would be desirable to as not everyone uses Facebook.
Thanks for any help/info/suggestions.
Unfortunately there is no one point where you can check if a give account on one service is the same person as an account on another service.
One way is to drop a cookie on their browser when they log in with Service A, this cookie would indicate te service the user used to log in the last time. Then the next time they arrive on your site you can check for your cookie and then only show the login service they previously used.
Another option to make it more difficult to log in from multiple services is to request the email address of the user from the service and see if it already exists in your Database under a different account?

How can I create an XMPP account?

I have a web application using XMPP for chatting. The only real problem is that users have to create their own XMPP account on the right server. I'd like to automate this process.
How do I automatically create a new XMPP account for a new user ? How do I know what address can be used or not for the account ?
There are a few different approaches:
Have the client register in-band. They can then choose their username themselves.
Connect to an existing user database, or interface with it directly.
The server might have some CLI or Web-based management tool that can be used.
As ggozad wrote, use the Add user command defined by Service Administration.
You need to implement (and your server to support) XEP-0133 Service Administration and in particular the add user command. You can create random user ids or generate them with some logic and store them somehow to check for uniqueness. The get-registered-users command might also be of help.

Kerberos, delegation and how to do this correctly?

I've got two separate homemade applications that need to communicate among themselves. One is a frontend application (asp.net actually), the other is a backend interface to an accounting application. The backend interface was not created specifically for this frontend - it is a generic interface that many other applications use to integrate with our product.
For the convenience of users we wish to provide a Windows Authentication in our frontend application. That means however that we need to pass the credentials on to the backend application which has to check them.
We do not wish to set up our frontend as a "trusted" application to the backend which can authenticate itself as any user. If the frontend was to be hacked, it would then also compromise the backend system.
As I understand it, one way to do it with Windows Authentication is Kerberos Delegation. However this requires to be explicitly enabled for the user that is to be delegated, and the machine which does the delegation (the server with our frontend). By default these options are disabled in Active Directory, and I suspect that many sysadmins will have their reservations about turning them on for all their users.
Also, I'm not really sure that this is what Kerberos Delegation was meant for. I don't need our frontend to impersonate the user that is connecting. I just need to prove that this user has authenticated itself to me.
How would you do this?
I'm not clear what you can and can't do with your use case but I can answer the question what Kerberos Delegation was meant for.
First let's talk about what Kerberos does prior to delegation. It is important to understand this part well because it is subtle.
Kerberos authenticates the identity of BOTH ends of a communication between two end-points across a network, those end-points can be interactive users or services running on a computer.
This is strong authentication so it will not allow a man-in-middle attack in any form. If set up correctly an end point can guarantee they won't be compromised. To the level of the service name (if you are connecting to IIs on a machine it is different than connecting to SQL Server on the same machine). It makes heavy use of modern encryption techniques and requires the use of secure certificates. The details of the authentication protocol are complicated and not worth going into now, but it involves about 20 different distinct steps of confirmation between the two authenticating end points and authentication server (in windows the Domain Controller is the authentication server).
So what the heck is delegation?
Delegation is a Microsoft extension to the Kerberos standard which
allows a trusted source to continue the authentication to another
end-point.
This allows you to act as a "man in the middle" -- however many settings have to be explicitly setup, certificates installed, etc to allow this to work. It is far from simple. (EDIT: Here is another SO answer on the details - https://stackoverflow.com/a/954154/215752)
So, for example, you could have someone authenticate to a website and then have the .NET code connect to an SQL Server AS THE SAME USER to read data with that user's rights.
Now to answer your question, since I'm not sure what you want to do I present three choices:
1) You want to connect to the back end system as the SAME user as the one authenticating at the website.
In this case Kerberos delegation is perfect -- it does exactly what you want.
2) You want to connect to the back end system as a DIFFERENT user than the one authenticating at the website (eg a service account).
In this case you don't want delegation. Kerberos to the website and Kerberos (as a different user) to the back-end will work great.
3) You want to connect to the back end system as the SAME user some of the time and as a DIFFERENT user other times. (For example, you need to validate this is a legal user for the back end system, but want to perform trusted actions as a system account other times. This is (in my experience) the most common use case.)
In this case you use both. Delegation for the connections which need to validate the user identity and then revert to the service account identity for the times when you need system access to the back end. (A previous question of mine went into the details of how to revert to the system identity on the .NET platform see How to "un-impersonate" (un-delegate?) in Kerberos.)
Here is a post describing how Kerberos works and how to set it up.
ASP.NET passing along Windows Authentication credentials
Actually Kerberos delegation is designed exactly for this use case. But the challenge here is craft this on a legacy system and with AD's settings that you do not want to change.
One possible hack is to have the Front End just send the user and the time of authentication but the backend can query the Active Directory Event Logs to determine whether that user has authenticated to the Front end. This requires you to use WIndows Event Log API.and also play around with Event Log settings in AD to log the issue of service tickets. (MY recollection is that this is the default)
-