Let's say I want to create environment's domain for users with different roles: Regular role and Admin role. I need user's auth token for every request, so I set header value for /auth/signin/ as a dynamic value:
Respone Parsed Body/auth/signin/ > token
But when I switch user environment from one role to another, dynamic value for token doesn't count new environment. And every role uses the same token for authentication.
What is the best way to work with different roles?
That's a good question. Currently "Response Parsed Body" dynamic values are using the latest response, regardless of the current selected environment. (We're going to make it possible in a future release)
What I suggest for now (as a workaround) is to create two different auth/login requests, one per environment/role, and a new environment variable that would point to the right request. I tried to explain this through this screencast: http://cl.ly/1X0B2H2o1o1S
Related
Just trying out Paw for the first time … I think this is a basic question but trying to understand how to use the various concepts:
Documents
Groups
Requests
Environments
Sessions
For this example, let's say I am wanting to work with the Sonos API, so I create a new document (⌘N) and I name it "Sonos".
Next, I create my first request which returns my households. When I created this request, I had to configure OAuth 2.0 auth. So far, so good.
For my second request, I want to return the groups in a household. How do I set this second request (and subsequent requests) so that it inherits the auth config created in the first request? Groups seems to be arbitrarily folders, environments seems to be more for specifying dev/prod etc and I am unclear what sessions are (but wondering if that's what I want).
This is a long way of asking "how do I nest requests so they share the same auth config"?
I want to save some small info (say, user's device id) about the user, after or during sign-in. This data is dynamic, and I'd like the lookup to be very fast (without database hit), as I need it in many controllers. I tried adding it to user's claims like this:
((ClaimsIdentity)User.Identity).AddClaim(new Claim("UserDeviceId", userDeviceId));
to subsequently retrieve it like this: User.FindFirstValue("UserDeviceId") inside any controller. But it seems that the data is not persisted between requests! It returns NULL on another HTTP request.
I use standard SingInManager.PasswordSignIn() to sign the user in. I don't have claim store at all - I don't use default Identity EF implementation, I supply my own stores (IUserStore, IUserPasswordStore, and IUserRoleStore implementations). But even if I did, this data is dynamic and should not be persisted to / retrieved from a storage at all. The data is available upon sign in (basically client app sends hardware id).
As I understand, the dynamically added claim gets wiped out because it is never injected into the cookie, when I add it to User.Identity it just adds to in-memory instance, which gets overwritten by the cookie at next request. (or at least that's my best guess).
Is there any solution to this problem? I'd really like to avoid setting up Session mechanism, all I need is a single small value persisted across the requests, and even though strictly speaking it might not fully qualify as a "user claim", it is (conceptually) very close - it is a device id the user is currently connected from.
I use User.FindFirstValue(ClaimTypes.NameIdentifier) in my controllers to get userId without any performance impact, and it is very convenient. It's setup by Identity itself obviously. I'd like to have similar mechanism for another identifier, preferably without rewriting half of Asp.Net Identity :) Is that doable? If not, what's my best alternative (besides setting up Session storage or supplying the value in every request)?
For client security and privacy reasons, we want to deploy a unique database for each client while using the same website.
I envision that during the session_start event, we would determine which database to use for them (by looking at the subdomain they come in on) and set the connection string in a session variable. Then on every page_init, we'd dynamically set any object's connection string. In code behind, we'd do the same thing with the connection string.
Is there a better approach to doing this and will setting the connection string in page_init work? Is using a session variable wise? I've tended not to ever use them except when no other solution was possible.
The problem with the model itself it is really complex and can let you with some errors specially when we are talking about changes in the database. Imagine that you need to add an extra field on the interface. if you have 100 clients this will mean updating 100 different databases. when we talk about dealing with downtime them things get even worst.
I would do with that in a light different abstract your database layer create one api that will call the database. And from the website you always call the api passing the domain that you want the data to come from.
You can ask me what advantage this will give to you. The biggest one that you will see it is when doing upgrades and maintenance. Having one api per client it is a lot better to think them having one database per client. and if you really want to have just one (I would really recommend having one per client and deploying automatically) you can have a switch on the call and base with some parameters that you pass to the api ( can be on the header like the subdomain on the header) you can chose what database to connect.
Let me give you a sample scenario and how I would suggest to approach this scenario (that is true for database or api)
I want to include a new data field. So first thing it is to add this field on the backend (api or database) deploy this new field if it is one api you can even test that calling the api and see that the new field it is now returned that is not a problem for your ui because it is just a field that it does not use. after that you change the ui to actually use this field and deploy that to production.
is it possible to assign a value to a ServerVariable("Something") using the code? instead of doing it via the IIS?
something as simple as this?
Request.ServerVariables("LOGON_USER")="test"
i also found the following at another forum:
Request.ServerVaria bles.Add(name, value)
but i keep getting the same error on both:
"Declaration Expected"
some background:
i am trying to do is pass in the ("LOGON_USER") variable from one applicaton to another (on a different domain), to somehow allow for single sign on. I now pass hidden variables to the new server and then want to assign them to proper servervariables.
would I then need to edit response or request? am i waaay off on this?
Single sign-on is not usually implemented in this manner. Typically you would authenticate the user in the first system, create a secure token, then pass the token along with some identifying information to the second system. The second system would validate the token and the additional data, and if successful, authenticate the user in the second system (usually by creating an auth cookie).
This link gives you an overview of one approach, but you can Google for other techniques:
http://msdn.microsoft.com/en-us/library/ms972971.aspx
You can set server variables (although you would usually want to change the response rather than the request), and the most likely place to do this would be in a custom HttpModule. You can find more info here:
http://learn.iis.net/page.aspx/686/setting-http-request-headers-and-iis-server-variables/
and
http://forums.asp.net/t/1125149.aspx
I have two web applications and both are developed in ASP.NET. Now I want to provide a feature which enables the user to click from one URL in application site (one virtual directory of IIS) A to the other URL in application site B (another virtual directory of IIS).
I have two ideas to implement them, but both of them have issues. I want to know what solution should be optimum solution?
Solution 1: using cookie, so from both application sites, we could retrieve user ID information from reading cookie, but I am afraid if cookie is disabled in browser, this "jump" feature never works.
Solution 2: When the user redirects to an URL in another site, I could append user ID after the URL, I could redirect to this URL in another site http://www.anotherapplicationsite.com/somesuburl?userID=foo, but I am afraird that in this way userID will be exposed easily which raise security issues.
I work with this sort of thing a lot. What you're looking for sounds like a candidate Single Sign-on solution or Federated Security.
You might try doing something similar to the following:
Create a simple db or other sort of table storage with two columns "nonce" and "username"
When you build the link to the other site create a GUID or other unique identifier to use as a one-time nonce, passing it as a querystring ?id=. Insert an entry into the table with the current authenticated username and the unique identifier you created.
When you reach the destination of your link, pass the unique identifier to call a webservice that will will match up the identifier with the username in the database you inserted before jumping to the second site (secure this with ssl).
If the nonce checks out with a valid username, you're all set. The webservice should remove the used entry and the table should stay more or less empty any time you are not in the middle of a transaction.
It is also good to include a datetime in your nonce/username table and expire it in 60 seconds or less to minimize the risk of replay attacks. We also require client certificates for external applications to call the webservice in order to verify the identity of the caller. Internal applications don't really necessitate using client certificates.
A nice thing about this is that it scales fairly well to as many sites as you would like to use
Not perfect security, but we've never had a significant compromise with a such as system.
As long as you have a good authentication system in place on the second website I think solution 2 is the one for you, taking into account the remark Andrew made about the sensitive ID's of course.
For more information on encryption: check the documentation of the FormsAuthentication.Encrypt Method . I think they even do something with writing a value in a cookie in that example.
If you put the userid in a query string and that's all the 2nd app uses to allow login, what's to keep me from manually typing in other users id's? You'd still have to prompt for password on the new site.
I'd use a database to hold login information, and have both sites reference that same db. Use it like you'd use a session.
D
I don't think 1) will work due to browser security (cookies from one domain cannot be read by another domain). I would go with 2), except I would encrypt the querystring value.
EDIT: For more info on cookie privacy/security issues, check out the "Privacy and third-party cookies" section here.
What are you using as the user's id? If you are using their social security number or email (something sensitive) then you are going to want to encrypt the value before you put it on the query string. Otherwise (if the user's id is something ambiguous like an integer or a GUID) it should be fine to put the id on the query string.
using cross domain, you can not SHARE the session, so I was thinking about POST
idea 1
if afraid of "showing" the username in the address, why not sending a POST?
<form name="myForm" action="http://www.mydomain.com/myLandingPage.aspx">
<input type="hidden" id="userid" value="myUsername" />
click here
</form>
but then... off course, "View Source Code" will show it
idea 2
then.. I remembered that I do the same, but sending a Encrypted string like:
http://www.anotherapplicationsite.com/somesuburl?userID=HhN01vcEEtMmwdNFliM8QYg+Y89xzBOJJG+BH/ARC7g=
you can use Rijndael algorithm to perform this, link below has VB and C# code:
http://www.obviex.com/samples/EncryptionWithSalt.aspx
then in site 2, just Decrypt and check if the user exists... if it does, continue, if not saying that the user tried to temper the query string :)