I'm designing restful service and one of the entities to maintain - user accounts. I'm doing it in .NET and using membership provider.
Here is what I have:
/users/ GET - returns list of users
/users/ POST - can create or update
multiple users (post array of User
objects)
This POST won't matter if you updating or creating user
Problem I have: How do I create service to change password? Changing password is separate from updating users procedure. I'm thinking something like:
/users/{userName}/password POST - to
change user password.
But then I have to pass different object here? (I use JSON)
Do you have any suggestion on how to layout URL? And should I really create another object? MembershipProvider requires old and new password to change
Well the question has to be whether we see the password as a resource in its own right, or not.
In my user dbs, I store all my passwords (salted and stretched) in their own table, so I can easily present the password as a separate resource. But just because you don't have that fine grained control doesn't mean you can't do the same - but I wouldn't consider implementing a GET for the password, ultimately you need an authentication service for that, which should follow some kind of protocol.
A rest service is free to represent its data however it wishes, with no real regard for the underlying structure so, given that, I think you're free to do it as a separate resource if it makes sense in your case.
You could include in your user data a uri to be used for changing the password. The client would have to know the type of data to send (so yes you will need a dedicated resource type to handle the change request), and that the uri should be triggered with a POST request.
If I understand your question, you'd like suggestions on how related to the Uri layout itself. The suggestions below is related specifically to designing a Uri that someone can use to change a password.
Never include any sensitive information in the clear in URIs, even if it comes over HTTPS, as that information may be written to log files on the server, or worse, recorded by analytics or monitoring software. Make sure sensitive information is sent as part of the body or part of the header.
Here are a couple of considerations why changing a password with a RESTfull service may require its own Uri:
Prevent accidental changes to a password when updating a user details.
Whenever this method changes, you may need additional security reviews as any defects therein that allows a anonymous user to change the password of an existing user will allow that anonymous user to hijack the account.
You may also want to include other additional security features like notifying a user that their password has changed and invalidate any OAuth tokens issues to applications. The membership provider is great, but doesn't provide this additional measures.
Since it is a different Uri you can monitor its usage and correlate it to IP Addresses allowing you to detect whether someone is trying to compromise a user account.
You can just PUT a data contract to https://example.com/users/{id}/password:
[DataContract]
public class ChangePassword
{
[DataMember]
public string OldPassword { get; set; }
[DataMember]
public string NewPassword { get; set; }
}
The latter assumes you'll authorize whether the client can actually perform this action. You may want to look at PUT vs POST in REST whether to use PUT or POST. In addition, the book RESTful Web Services and REST API Design Rulebook has been invaluable to me when designing RESTfull services, including Uri layout.
Related
I know that Request.Headers["Origin"] gets the origin header of a request, but this is changeable on the client-side by setting the header manually. Thus not that safe.
Is there such a value that contains the original, readonly/unchangeable origin of a request? Like the one CORS is using?
I need this value to check if the request is officially coming from the site it's supposed to come from. The trick is that I need it in the controller method to search an object in the database based on this value and a key only used for that site.
The problem with CORS is that it can whitelist a list of URLs but not check if the site and the key belong to each other, thus can whitelisted site 1 access the data of whitelisted site 2 if it mimics the Request.Headers["Origin"] and the key of site 2
Unfortunately (or perhaps fortunately?) there is no reliable way to check this from the data that the browser sends to your server. The user is able to forge any and all information that you receive from the browser.
This is why mechanisms that need to reliably determine the origin of a user use some sort of token mechanism, public/private signatures, certificates and the sort to determine it. Unfortunately this is never as simple as looking up some information that the browser provides you with, so it seems like you might need to redesign your whitelisting mechanism by relying on something else than origin, possibly implicating single-sign-on measures (like SAML). It's hard to provide further suggestions without more information on the underlying problem that the origin-check is intended to solve.
I'm designing a site using ASPx and IIS, where clients can sign up and then offer services to their clients. For example:
if you go to http://www.mywebsite.com you can sign up for your mywebsite.com account as a business owner. When you sign up, you are given a Site ID (Example: AA1234).
http://www.mywebsite.com/AA1234
What I want to do is always include the Site ID in every url (Inbound and Outbound). The Site ID is stored in a session variable based on the initial incoming request.
Does anyone know of a good way to do this - or a different design that works better than this?
Thanks
Your question is nebulous at best. However...
Wouldn't this be what cookies are used for?
In particular, if your user is authenticated (this is generally achieved in asp.net with an auth cookie), then at the server, you would have tools at your disposal that allow you to recognize the user and provide a different experience according to whatever criteria you choose. Most likely, these details might be stored in a database.
Found the answer in this topic: http://www.tek-tips.com/viewthread.cfm?qid=1149673
The last response from BoulderBum is exactly what I needed.
Using the HTTP module I will take the /AA1234/ URL and point it to /Company/.
On the way out, I replace all instances of /Company/ with the site id again
I have a bit of a unique situation here. I'm making a web application that is going to have
the ability to login with different web applications credentials. For example you can login/register with my site or you can login/register with your YouTube account. I'm not using OpenID because I need to have access to YouTube's data in this case.
I'm using ASP.NET MVC 3 EF4 with custom Membership, role, profile providers.
The problem is user names can't be unique because someone with a YouTube user name could have the same user name as someone that registered with my site. So I got around with by specifying a user type in my user table. This is pretty much a composite key (user id and user type).
I have a custom authorize attribute that is checking for the role that the user is in but now I need to implement a custom IPrincipal because I need to pass a user type. Only problem is where do I store that? the session?
Originally I thought this is what the Application table was for, and I had momentary success with that but read there is threading issues, and I was getting session faults all over the place it wasn't that great :(
I'm wondering what the best way to do with is because I can't use the overridden methods in the providers because I have to add a UserType parameter to some of the methods, but then this breaks the functionality of the provider.
EDIT:
I basically need to have the ability to change the ApplicationName at runtime pro-grammatically. I tried doing this, the only problem was when I stopped my development server but left my browser open then ran my dev server again it wouldnt keep the application name.
EDIT:
I've changed my application to use OAuth, I never found a good solution.
I basically need to have the ability
to change the ApplicationName at
runtime pro-grammatically. I tried
doing this, the only problem was when
I stopped my development server but
left my browser open then ran my dev
server again it wouldnt keep the
application name.
If you need to change the ApplicationName, this means you need to select a provider at runtime.
The only way to do this is to NOT use the singleton "Membership" as it uses the provider defined in web.config.
Instead each time you need your provider use :
MembershipProvider userProvider = Membership.Providers[UserProviderName];
Just set UserProviderName the way you want. I would go with a custom global authorization or preAction filter which detect the provider from some cookie or other session variable and put the provider in the HttpContextBase.Items collection which lives for one and only one request.
The best answer to this problem is answered on stackoverflow here: Membership provider with different ApplicationName in area
Here's the code they used:
Membership.Providers["MyOtherProvider"].ValidateUser(username, pwd);
Ryan,
Hmmm... can you work-around the problem by prepending the issuing-authority (local or YouTube) to the username field itself... Example usernames: "LOCAL/corlettk", "YOUTUBE/corlettk"???
Ok, you'll need a custom Authenticator in order to split the complex-string, and flick-pass the login-request to appropriate underlying Authenticator... but once that's done, (I guess) you're all set to deal EASILY with the much bigger problem (from your perspective) of Authorisation.
I percieve that you're a smart guy... have you considered-and-dismissed this approach allready?
Cheers. Keith.
PS: Yes, I'm a hacker... but I have bad habit of hacking stuff up that WORKS... so they've given-up trying to educate me.
I know this has been posted before, but never really answered, I'm using the DotNetOpenAuth to try and do GoogleID login, and every time I do details = OResponse.GetExtension<ClaimsResponse>(); I always, always, always get back null, I don't get whats the point of the GoogleID if I can't get back any information, I would think at the very least I would get an email address, so I could associate it other login information in my databse. I just don't understand could really use some help, Im probably just looking at openID in the wrong way.
I'm using ASP.NET and looking to use openID/Facebook as my sole means of logging in users, I really don't want to mess with membership roles, or extra junk that ASP.NET likes to add.
Yes, this has been asked and answered many times. Google does support AX. But it ignores any attributes marked as "optional". So if you want the email address, you have to say that email address is a required attribute.
The ClaimsResponse extension you're checking for isn't AX -- it's Simple Registration. But if you have AXFetchAsSregTransform behavior turned on (highly recommended) then it allows you to just use ClaimsRequest and ClaimsResponse exclusively, and DotNetOpenAuth will automatically translate to and from AX behind-the-scenes for you.
Alternatively, you can use FetchReqest and FetchResponse to speak AX directly to Google.
But (and I can't hammer this hard enough), do not use the email address as the user's unique identifier!!! Instead, use the IAuthenticationResponse.ClaimedIdentifier string as the unique identifier. Email address should generally be considered just a helpful hint that can be used to prefill a registration form. You shouldn't even trust that the email address you get is really under the user's control (that's one reason why it shouldn't be considered their unique id) since the Provider can lie to you. Google and Yahoo are two providers that promise (if you choose to trust them) that the email addresses have been verified, so you can skip the email validation step for users from them if you wish.
It doesn't appear that Google's OpenID server supports AX or sreg.
My applciation works as follows
[user]----username/password/domain----->[WCF service]
then i access the domain server to see to which actual DB the user is associated,
after getting that, i validate the user in his actual DB(DB is per domain)
the problem is that i need a place to store the domain name for the following requests against the db.
for example,if the users calls a WCF service operation:
Test()
first the validation procedure is called, (WCF UserNamePasswordValidator) which validates the user password(which is sent as part of the header for REST or as part of the SOAP), and the next function to be called is the Test, but by then i cant tell the domain of the user(to actually serve the request agains that domain..)
I dont want to change the signature of each domain to
Test(string domain)
I cant simply access the headers since i expose the same methods both as REST and as SOAP and the authentication is different for each of them..(one is with headers as with Amazon S3 and the later is using the SOAP standard)
so basically i'm looking for a global, per call storage.(i want to avoid the Per-Call initiation method)
thanks.
EDIT:
Maybe i should use the ThreadStaticAttribute? will that work?
This will not work. You can't store anything in UserNamePasswordValidator. It even doesn't have access to OperationContext because it runs on different thread.
The way to do this is create custom message inspector and extract the information from custom message header to custom operation context extension as Frank mentioned.
WCF knows a Current OperationContext. You can write your own extensions for it. Unrelated to this issue, I used the same mechanics in this NHibernate Session management here, which may work in its concept for you as well. It accesses the InstanceContext, but the concepts are similar.