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.
Related
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I’ve built a google action that talks to my bespoke web Api.
The actions code currently has personal details hard coded into it. I need to make it so that when someone uses it for the first time it asks them for a username password and URL.
Is there a way to do this? Or maybe there is a way for a user to add those details to there google account in some way that the action can read them.
Alternatively is there a way to publish an action so only specific users can access it?
In general, asking for a username and password is a bad approach for Actions, for several reasons, and asking for a URL can be quite a mess. Particularly if you're expecting the user to access the Action via voice or a device that doesn't support a keyboard.
The better approach is to use Account Linking to connect their Google Account to an account they have created on your system. If you need additional one-time configuration information, you can have them provide this information for their account via a webapp, store it in a datastore of some sort, and then access it when they contact your webhook via the Action.
There is no way to have the Assistant enforce access to a production Action. You can publish an Alpha release to up to 20 accounts, but this is still treated as a "test" version.
My company has userbase of course, but I want to allow users to login and use my applications with their social accounts e.g. Outlook, Facebook, Gmail. Something that is usually not clear to me when I read resources on the Internet on the topic is how to map the social credentials with ones in our database? I know we should use an API platform or something like that, but the user identity part is not clear to me.
You basically need to, as you noted, tap into the provided response and transform or link or provision it to existing identities in your own userbase. A lot of this depends on your method of delegating authentication to external provides and things they expose back to you as part of the user profile. You basically need to grab the user profile, parse it and then determine which field can be used to link that profile to an existing account, and then establish the authentication session based on the final result.
Here is a link to a technical walkthrough that describes the same process with an SSO solution: https://apereo.github.io/2018/04/20/cas-delegated-authn-account-linking/
I'm trying to switch my site from the asp.net membership sql provider to using facebook connect to do OAuth single signon. I'd like to keep using the role provider as it makes it pretty easy secure sections of my site by flagging the controller class or controller methods with the Authorize(Roles="...") attribute. The site isn't live yet so I'll be completely ditching the Asp.net membership provider if I can. (keeping the roles and profile provider)
I've got the facebook connect logging the user in and I can get his info. But how do I associate that with a role?
I'd like the system to automatically add a new user to the "SuperHero" role after he authenticates and authorizes my app.
Am I on track here? Is there a better way to handle roles when using OAuth2? I'd like to add other OAuth providers later.
An alternate approach would be to keep the asp membership, then when I user logs in through facebook connect, I could find his record and sign him in with aspmembership. But that seems sloppy.
Some sample code would be great and I'd think others would find it helpful too.
thx,
Dan
The easiest way to do this ime is to actually implement a FacebookMembershipProvider for yourself. That way it ties in to all the other providers naturally. The main downsides are a) a lot of code b/c Membership is a fat interface, and b) some cruft b/c it assumes you'll be doing passwords, etc, which obviously you don't need for OAuth.
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.