Found this official ACS demo http://www.fabrikamshipping.com/ while researching on ACS.
In the app itself, when logging in with one of the providers ( I chose Google ), I can see in the browser history the URL that contains the claims returned from ACS. It's the URL that starts with :
https://fabrikamshipping.accesscontrol.windows.net/v2/openid?context=pr%3dwsfederation%26rm%3dhttp%253a%252f%252ffabrikamshipping%252fcons...
Going to this URL logs me in the app, even after clearing all browser cache and cookies.
So if I log in to the app from some public computer, and then log out, my account is exposed by going to this URL in the browser history.
I know this is the standart way that ACS Identity handling works.
What am I missing here ?
You are not missing. This URL will log you in, even all cookies are cleared. However, when going on public computer you have to be more careful about your credentials. Clearing history will wipe this URL from browsers history.
Also, I don't actually see the claims URL in my history.
Another way of protecting your personal data is using "In Private Browsing session" for the browser of your choice. Note that it is very hard for someone to see, not to mention remembering that URL. You got it, because you copied from the browser at the moment of redirecting.
I opened the same thread in Azure official forums :
http://social.msdn.microsoft.com/Forums/en-US/windowsazuresecurity/thread/8f35d6d7-fe0d-4589-9502-54c85714979a
It seems like a known issue. I will update the answer here as soon as a solution will be provided.
Related
We have an app which stores some information in the browser's local storage via javascript. The app was rejected in the review phase because it saved these entries without adding them to the cookie consent. From what I can see we can only add cookies to the cookie consent via the app's manifest. How could we add these local storage entries to the consent? We can add them as cookies in the manifest with the same names but that would create these as cookies once the consent is approved, which is not ideal and unnecessary. Is there a better way?
In theory you could try to override the CookieConfiguration plugin in a way, so your local storage entries show up in the cookie consent window, yet do not actually set the cookies once accepted.
Personally, I wouldn't bother to go that far, as it might also lead to other issues in the review process. For now I would simply let the entries be set as cookies to get through the review process. Please create an issue on the issue tracker explaining the need for local storage settings in the cookie consent window.
We're setting up SAML2 SSO using Azure AD, and we set the Reply URL incorrectly the first time. Now, I am unable to login with the original credentials we tested with as they are being redirected to the incorrect Reply URL. Any new user accounts work fine.
I'm unable to find any documentation saying how long this type of caching may take place, but I've cleared all client-side caches and am at a loss for what we could do without recreating the app (which we'd like to try to avoid).
I've been reading for the last hour but it's still not clear for me how to automatically authenticate the current windows user in my node js application.
On my office PC, I'm already authenticated with my AD user when I access our company portal in Chrome (as it was added as a trusted sites). So the main question for me is what do I have to do to automatically detect/authenticate the user in my nodejs app if I add my site to the trusted sites? I'm pretty sure the browser must do half of the job as it probably sends some kind of data (hash) in the request, based on which the application must authenticate the user. I suspect this is the "www-authenticate: negotiate" header as I noticed this sends a hash in the request when I access the portal.
So far, the only tracks I'm still investigating are:
https://gist.github.com/charlesdaniel/1686663
But it's still not very clear for me how this automatic authentication works and what are the leads I should follow next. The entire process is still unclear to me
I appreciate any advices on this or at least a mid-level explanation on what happens behind the scenes when I access a page in Chrome and it automatically authenticates me. Thanks
I am developing a healthcare related web app and part of HIPPA compliance is that public available web apps need to enforce certain log-out behaviors. One such requirement is that when the users clicks "logout" in the app they must be logged out. Relying on the user to close the browser to clear session storage is not an option.
I am using ADAL-js with angular to handle auth for my app. When you log into the app login.microsoftonline.com stores cookies. As a result if you navigate back to the app you are auto logged back in without being prompted for credentials. That violate the requirement described above. If you use the dev tools in chrome to delete the cookies for that host the problem goes away.
Does anyone know of a way with the Azure AD Oauth service to enforce this more strict requirement?
We ended up opening a bug against Azure AD with Microsoft. They have since deployed a fix. This all occurred earlier this year. So this update is a bit late.
ADAL.js exposes a couple of functions clearCacheForResource() and clearCache() in the adalAuthenticationService Service. After calling adalAuthenticationService.logout(), you can clear the browser cache by calling the above functions. They should clear the cookies.
You can also try using the $cookieService provided AngularJS, for better control on the cookies.
We're building an application which uses ACS. Our usage scenario looks like this:
The user gets a URL like this one https://our.application.com/?requestId=123456 via email and clicks on it
The user gets redirected to the LiveID login screen
After logging in, ACS forwards the user to us, but to https://our.application.com/
Unfortunately, it seems that the "Return URL" setting in the "Relaying Party" on the "Access Control Service Portal" is just a fixed string. Is there a way to propagate the original request to it? If not, what would you suggest as a workaround?
The answer is actually yes, but not without a little work. In step 3, your return URL is being overridden by the one you have configured in your ACS RP by the default ACS login page. This is the page, which ACS hosts for you by default, where you choose your identity provider. (You may not always see it in the browser; it will redirect automatically if you only have one IDP configured.)
You can tell ACS to use a custom login page that you host yourself so that this original URL gets saved. You can download the default ACS login page from ACS portal as something to work off of.
The tricky part comes from the fact that different identity providers using different protocols use different mechanisms to save this original URL.
Some further discussion and code samples about this can be found here, and you might find further solutions to this problem elsewhere on the web:
How do I get the return URL working properly again after downloading a login page from Azure ACS?
I believe the answer's no, and I would suggest using a cookie to store the parameter.
If you want to provide a "returnUrl" via ACS + Microsoft Account you can query the ACS login pages via the IdentitiyProviders.js and pass a "context", e.g.: https://MyACS.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=MyRealm&reply_to=&context=foooobar&request_id=&version=1.0&callback=&wfresh=0
As a result you will get the Login-URL for Microsoft Account with the wctx parameter:
https://login.live.com/login.srf?wa=wsignin1.0&wtrealm=...&wp=MBI_FED_SSL&wctx=cHI9d3NmZWRlcmF0aW9uJnJtPXVybiUzYW9uZW9mZml4eCUzYWRldiUzYWRlZmF1bHQmY3g9Zm9vb29iYXI1 <-- foobar.
After the login process your configured returnUrl is invoked with the wctx parameter (in my example you will get "foobar").