I want to close users (which I'm now successfully importing through Admin API) without their consent when they leave our company and their domain email gets deactivated.
I found the following methods that are related to closing users:
https://developers.docusign.com/docs/admin-api/reference/usermanagement/esignusermanagement/closememberships/
This one says: "This method requires user authentication. It will fail with an application access token." So it's a no go for me because I have no way to get the user's auth form a server-side background application.
https://developers.docusign.com/docs/admin-api/reference/bulkoperations/userimport/closebulkuserimportrequest/
It says "Given a CSV list of users, close their accounts."
But the API method does not accept a CSV file as a request parameter! There is no way to pass any user data to it.
Maybe I could use eSignature API instead of Admin API - it has https://developers.docusign.com/docs/esign-rest-api/reference/users/users/delete/
But that one says "userId string
The ID of the user to access.
Note: Users can only access their own information. A user, even one with Admin rights, cannot access another user's settings."
So, I'm not sure if even an Organization admin with their JWT token can use this method to delete other users? Anyway, most likely, this method will require another JWT token for eSignature API, which in turn will require more infrastructure stuff (config variables, keeping token alive) and I really would want to avoid that and stick to the Admin API only, if possible.
I'm using .net DocuSign nuget package, and I see that CreateBulkImportCloseUsersRequestAsync also has only OrganizationId as the argument. But I don't want to close all the users in the organization, I want to close them by IDs or emails, whichever is accepted by DocuSign.
How do I close user accounts properly? No matter, if it's a bulk or single-user method, as we would want to close them immediately for every separate account.
You cannot close user memberships (note that the term "account" is incorrect here) you can only disable them. You can contact support, but even they cannot really completely eliminate a user membership like it never existed. There are reasons why it must stay in a dormant state.
To explain the difference between users and accounts, here is a diagram:
Related
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
ASP.NET newbie question. I'm starting with ASP.NET's Starter Site that comes with a set of built-in registration, authentication pages, and membership DB.
Now my question is, how can I restrict registration to my site? This site is for a patient practice and only patients need access.
I have read about roles, but assigning roles means the user has already registered. I don't want users created in the DB without being authorized either by email or other credentials that an admin will enter prior to registration.
Please let me know the best way to achieve this modification to the starter site template.
Thanks in advance.
As siva.k mentioned in a comment you can remove the registration process from public access, that means users will not be able to register by themselves, an administrator must be in charge of creating users. This implies that you will need user security roles...at least if you don't want your patients to have access to administrative areas such as user management.
Another approach which will require a bit of more effort is to "send email invitations to your patients". Someone perhaps an administrator simply need to enter (at least) an email address and the system would trigger an email inviting the user to register. Obviously, this will require to have a registration page/view to be publicly accessible, but protected to only users who have been sent out an invitation. Determining whether the user is genuine or not it's quite simple. At the time the system sends out the invitation, it logs an entry in a database record...say an email address, a random unique code and perhaps an expiry date to validate the invitation. The random unique code could be whatever you want but must be unique within the system and most importantly NON-SEQUENTIAL (as in incremental integers or something like that). This code can be sent to the invited patient in the form of a url query string parameter, this url is the link to the registration page. Then, the registration page will extract this code from the url, validate it against the database record, deletes the record and then serves the registration page. If the validation fails you can easily respond with a 403 or 404 http code.
As I said, it requires a bit of effort on your side but you could make it a robust solution you can report on.
I've created a asp.net mvc4 web site. I've implemented Form authentication also.
In this web site i want to block access to my web site client in a same time (if a client of my website is already open his or her account in a computer then that client can not get any permission to open that same website on the same time in other computer or any other browser of the same system).
I want to provide one paid service to user, and I don't want him to just share his username and password with many people to use my service simultaneously without paying for it. please help me soon
How can I implement this. do i need to maintain some login information in database or is there any built in tool available for this.
To my knowledge there is nothing built in, but you may be able to implement your own version of the ASP.NET authorization providers.
Upon successful login you would need to store the value of the FormsAuthenticationTicket in your database and associate it to your user record.
On every page load you would need to check the value of the ticket against the database record for that user. In case of mismatch the user would be logged out.
Using this approach if User A and User B were using the same credentials, User A was logged in and if User B then logged in, it would invalidate User A's session and they would not be able to view content at the same time. You could also log the activity when a session is overridden, along with IP address and User Agent to help you identify users that are sharing account details.
This feature is not built in.
I would add an "IsLoggedIn" bit column to my "User" table. Then you could check this column to see if the user should be allowed in.
The problem is going to be knowing when that flag should be set to false. It's easy enough to set the flag to false if the user clicks "logout" or in the "on session end" event, but I think you'll run in to cases where that's not good enough. For example, if a user logs in from a laptop and the laptop's battery fails, you aren't going to get any notification from the client that the user has left...
I think David has already given most of the idea (+1) , However for problems like closing browser without logging out, You can handle it in window.unload() event for setting the flag in your table .
I'm trying to implement "Act As" functionality for an ASP.NET application while at the same time using Windows Authentication and a custom role provider. Essentially what I want to be able to do is:
Use Windows Auth to get the current user's domain account to verify they are an approved domain user
Use a custom role provider to get permission information from a SQL Server database.
Implement functionality to allow the admins of the application to be able to "act as" another user, without requiring them to actually log into the application as that user.
The scenario I'm trying to fulfill is that an application admin is attempting to assist a user with a problem and clicks the "act as" button to act as that user and see the application as they would see it. So the Role Provider would need to understand that the current user is acting as someone else and get permissions information for that user instead of the current user.
My plan was to implement an impersonation feature that would delete the roles cookie and add a value to a session variable indicating that the user is currently impersonating another user. As the session is not populated at the time that authorization occurs however, this isn't possible. I don't want to use cookies as I don't want this to cause a potentially persistent state on the admins machine (such that the admin couldn't open another window to the app and either act as another user or view their own data).
I can't find a good way (without cookies) to save the "Acting as user..." information given that the session is unavailable. I'd like to use the role provider, etc., so that I can leverage the built in security trimming in .NET. This all may simply be impossible, but I'm hoping someone out there has either tried this before or has a suggestion for something I can attempt to implement.
Thanks in advance!!
See my answer to a similar question here
The gist of it is:
The way I did this, which is admittedly a little crude, was to have an
impersonation table in my database which contains the logon name of
the user who is doing the impersonating and the logon of the user they
wish to impersonate.
I added some override code so that when the user first goes to the
page (it uses Windows authentication), it will check to see if that
user has an impersonation set in the table and then place this user id
in an object in the session state. If there was no impersonation, it
would place the actual user id in this same object.
To prevent me from doing things to the user's data as them, there are
two properties in this object, one for logon_name, which is what is
used by the system for content-customization, and another called
NameForLog, which is used when logging any actions. All actions I make
will be logged as me.
All areas on the site that display user-customized content look at
this session object, so they will always use the impersonated ID and
therefore always show me what the user is seeing. Beyond the first
page and the logging code, it doesn't even know that it is me it is
dealing with.
For your scenario, you could implement a roles provider and override GetRolesForUser to return the roles for the impersonated user plus some role that will allow the impersonating user to access the impersonation functionality for the purposes of turning it off.
You could even return the impersonated user's roles with the impersonating user's roles in order to give the admin user access to all of their own features as well as the user they are impersonating, it all depends how much this would affect the usefulness of the feature in your particular scenario.
I have implemented something similar...though not exactly like your scenario but pretty close.
Admin Login (Has one role like Admin)
Then admin is redirected to "Select Client" Page. Admin can search Client by ID, Name, etc. From the list Admin selects a Client. I store the client ID in a cookie.
I have custom RolesProvider that calls my custom GetRoles(loggedinUserid);
GetRoles(int loggedinUserId) method then determines the type of the user i.e. if it's Admin or non-admin. If it is admin then, fetch ClientID from cookie. Pass loggedInUserID, typdofuser and ClientId to the stored procedure that will return all roles for the admin + all roles for that ClientId and return to roles provider.
This way I have all my menuitems for Admin available as well as menus needed for ClientID.
Admin can go to "Select Client" page anytime and switch to another client. When they select a client, new ClientId will be stored in the cookie.
Now you have two options after this:
You can let rolesprovider call this upon every request or
Store the fetched roles in HttpCache and update this cache whenever ClientId is changed.
Hope this helps.
I've read a bit about it at http://oauth.net/ , it's "a simple way to publish and interact with protected data" apparently.
I think it's exactly what I need to provide a secure way of accessing data from an android/iphone app via a REST web service, but I can't work out exactly what it is.
So, put simply, what exactly does it do and are there any (really) simple examples of it in action I can follow, preferably implementing something in c# that can be accessed from a smartphone app?
From the link provided by Craig Stuntz:
Open ID gives you one login for multiple sites. Each time you need to log into Zooomr – a site using Open ID – you will be redirected to your Open ID site where you login, and then back to Zooomr. OAuth lets you authorise one website – the consumer – to access your data from another website – the provider. For instance, you want to authorise a printing provider – call it Moo – to grab your photos from a photo repository – call it Flickr. Moo will redirect you to Flickr which will ask you, for instance, “Moo wants to download your Flickr photos. Is that cool?”, and then back to Moo to print your photos.
DotNetOpenAuth is a good C# library for Open ID and OAuth.
OAuth is an alternative way for applications to keep login data without having the real data stored at all.
When you log into some page, you usually have a username and a personal password, or any other sort of login credentials. Now, if you want an application to be able to do stuff over that login, you would need to give that application your original login data. Which means that you enter both your username and your password into the application. That isn't bad so far, but the thing is that if you want to stay logged in via that application, it needs to store your credentials. But to make it possible to send the correct login data to the actual page, it needs to store those in their original form (just with some encryption or something). So if someone knows how the data is stored in the application, they can extract your original login credentials.
This is a security issue and exactly where OAuth comes in. With OAuth, every application is identified by a consumer key and a consumer secret. Both are unique to the client and usually no user will ever get to see those (especially not the secret). Now when you want to allow your application to have access to the page, you start the OAuth authorization process. You simply login to the page and explicitely allow that special application (identified by the consumer key) to have access. If you do that, the application will receive another key pair, the access token and access secret. That key pair only works for your account and only works when used by the exact application (identified by the consumer key, and secured to be the original app by the consumer secret). Now all the application needs to store is that access key pair (together with the already stored consumer key pair) and it will have access to the page without ever seeing your original login data.
That way, nobody will be able to get your actual login details, and nobody else (or no other application) will be able to use the generated access credentials to access the page. And if you don't want the application to have still access, you can easily revoke the access key pair, so that the application won't be able to use it any longer.
So OAuth is just a way to protect your real login data. Apart from that it does not add any other level of security or something, it's just to secure your data.