I am building a Windows 8 application where I would capture and store credentials using the Password Vault. I would like to then use them for all HTTPS requests to a specific domain. This is easy enough for single requests but I would like it to be seamless. I cannot use the enterprise authentication capability in the manifest because these machines are not joined to a domain. I have looked at the Web Authentication broker but this seems to be directed towards using OAuth.
My question is, is there a way to either:
1) Enable Enterprise Authentication and white-list the domain to use
these credentials for (even though these machines are not domain joined)?
2) Use Web Authentication to somehow use
my credentials (that I capture during initial launch) for all HTTPS
requests without OAuth?
3) If none of the above work, what is the
best way to use credentials that are in the Password Vault for all
HTTP requests to a specific domain, rather than pragmatically
submitting them with each request? (want this to be seamless so I
can write HTML without calling on this JavaScript function each
time. Thanks!
I don't think this is possible in Windows 8. You need to submit credentials with each request using
WinJS.xhr() or XMLHttpRequest.open(), or update your service to support OAuth or OpenID.
Related
There is a sensitive page in my website, so I want to authenticate visitors before they opening a link like: www.examples.com/builder.
I know if I use cookie based authentication everything will be simple, as the browser will send the credential message in cookies automatically. But in my situation, I have to use token based authentication. Browser don't send token if there is no pre-load script.
So my question is how to achieve token based authentication when someone open a sensitive page directly.
As far as I can understand,
you're looking for a way to avoid double roundtrips to send authentication headers to your web-service.
If I am correct, then this would only be possible via service worker which is a not widely supported feature. https://developers.google.com/web/fundamentals/primers/service-workers/
If, depending on your requirements, you can't go for service workers, then, the only left option is to use cookies.
I normally have a secondary authentication flow which uses cookies allowing a web service to authenticate a user on its first get request (the one made by the browser).
There are also some spa framework which implement routing resolvers but this will require a double roundtrip (1. load javascript, 2. send the token).
I'm a regular reader here at stack overflow but this is my first question.
I'm developing an authorization-server using the OAuth2 specs. And I just got stuck with how do I ensure the first-party client authenticity while using the password flow. I read many forums and this is what I got:
Javascript single-page clients
This blog post by Alex Bilbie, he states that to avoid the client_secret problem we should just:
It’s simple; proxy all of your API calls via a thin server side component. This component (let’s just call it a proxy from here on)
will authenticate ajax requests from the user’s session. The access
and refresh tokens can be stored in an encrypted form in a cookie
which only the proxy can decrypt. The application client credentials
will also be hardcoded into the proxy so they’re not publicly
accessible either.
But now this proxy can be accessed by someone impersonating my
angular app. And then I came across this blog post from Andy
Fielder: How Secure is the OAuth2 Resourc Owner Password Flow
for Single Page Apps. He basically says to rely on CORS to
avoid impersonating JS clients.
It is a good idea to use both approaches to secure my JS app?
Native Apps (Desktop and Mobile)
In the case of mobile apps, I only found cases for Authorization
Code and Implicit flows. This is not what I want, as the redirects
will compromise the user experience. So my thoughts on this is:
I will use the ROP flow and then register the client with a
client_id generated for this particular installation and attach it
to the user account, receiving the access_token and a
client_secret as response. Any other token request made by this
client MUST carry this credentials (as the client_id is specific
for the installation, I will be able to check if this client is
already authenticated). This way if someone uses any credential for
impersonating a client, or even registers a bogus client, I can take
mesures to revoke the user and client access.
I know that this can be overthinking, and I also know that some of this matters doesn't avoid anything. I just feel that is my job to protect my API as much as I can.
I would really appreciate your thoughts about this matters! Am I really overthinking? Should I just use the concept of a 'public client' and carry on?
Thank you all and happy coding!
First of all, this problem is not a common priority because most applications are developed first with website, and after with the API. This is probably the reason because no one knows how to deal first clients with oauth2, because everyone have developed other ways to do that and oauth2 is needed only to grant user access to third party applications.
Even if you have develop the oauth2 authorization server only for your first clients applications (thinking about a single authentication mechanism instead of developing many), you should try to develop the authorization code or implicit grant types. You will realize that you need a way to check what user is actually logged in.
The two common methods are:
user session (based on Cookies)
user access from localStorage (based javascript)
In either ways you need to check your application security, user session is vulnerable to CSRF, localStorage are vulnerable to XSS. There are a lot of articles about how to secure your website against either, so I will not suggest anything here, you just need to know that they exist.
Now that you choose your authentication method we can start to do some consideration about:
Javascript single pages applications
Proxy
Having a proxy that filter all requests in my opinion is like to have a door with the keys always inserted. It's useless even build the door.
However, for session based authentication it's the only way to do it. Allowing session authentication on your Rest API will open to CSRF security issues, so you need to have a proxy layer that get the user session, retrieve the access token from the session and do the request to the Rest API adding the Authorization header.
CORS
With this method you need to store the user access token in the localStorage, because the token is retrieved from the Js client directly.
Using CORS you are sure that other websites cannot do requests to your Rest API from a browser. But your first client need to be public (ie: it does not have a client_secret).
Native Apps (Desktop and Mobile)
In my first application I tried to use the same mechanism that you suggest to secure the auth flow. However that type of mechanism require that you identify every user client in an unique way. This is not possible in iOS for privacy reasons and with some probability it will denied in the future releases of Android. So you should rely on a public client and add only the client_id in your native application code.
This means that your native app client/your js client can be impersonalized? Yes, and there is no way to prevent this with oAuth2 resource owner password credentials grant type.
The main reason about this is because oAuth2 is not for authentication, only for third-party authorization, and that grant type was added only for specific third-party applications trusted enought to use directly the user password. You could read more about this argument here and here.
At the end
You still need a way to auhorize your user, and I think that the best you can achieve using oAuth2 is what Auth0 did.
Essentially this Saas manage your users with an oAuth2 server + OpenID connect, so you are always managing your users like its a third-party application and everything works fine.
Indeed, you can see on this page that for mobile applications they suggest to use a browser based login form, because the native one can be impersonalized by everyone that decompile your application, but if you wrap it into an authorization code flow it works fine.
I have a main web-site that uses passive federation (ADFS 2.0)
This website has javascript that calls out to an MVC Web API site using jsonp.
I am trying to get this WebAPI to participate in Single Sign On (same machine, different port). However the passive redirects break the jsonp. (The STS returns its own script which the browser renders and i never get to redirect to the real url for my response script)
Is passive federation compatible with a jsonp webapi?
If not, how do I use Active Federation without username/password credentials?
i.e. The user will be authenticated via the main website before calling the webapi, so how do I leverage the fact they are already logged in, in the webapi?
The passive federation protocol won't work in this scenario as you are experiencing.
You have two options:
If your web api is being exclusively used by your website you can share the cookie that is generated by WIF when the user authenticates. To do that, if you are using different websites you should configure the <cookieHandler> section on WIF configuration to use the same domain and path and use a FQDN (instead of machine names), so that the browser identify both the website and the API as the same domain.
The second option is to configure the Web API to extract and validate SAML tokens (being generated during authentication). What you would have to do here is to save the token that was used for authentication (turn on the saveBootstrapToken on the <service> element of the WIF configuration), get it by using the claimsIdentity.GetBootrapToken() extension method and attach the token on the JavaScript call as an HTTP header like "Authorization: bearer ...the-token....". On the server side you have to get that and validate the token (programatically). Note that you might hit a quota in IIS because of the header length if the token is too big.
I have been tasked with setting up a server which uses a web based control interface using kerberos and active directory for authentication. I am using twisted.web as the web server. The issue is that I do not want user passwords coming through this server, but I don't know if it is possible for firefox and chrome to get access keys from the kerberos key server. Specifically it must work with firefox, other browsers would be a bonus. Is there a javascript library, possibly using HTML5 or a firefox plugin that allows for authentication to an untrusted server using kerberos? A flash application might also be possible.
Maybe you could through a reverse proxy in front of twisted and use http auth from the web app and delegate authentication itself to Kerberos via an apache or nginx module.
While the proxy will receive the password, the twisted server won't, in line with your use case. Requests would be intercepted by the proxy and delegated to your back end (proxy_pass) following a successful authentication.
This way your solution would work independently from any http client/web browser.
How would you combine OpenID with a RESTful web service?
The personal project I'm working on is using the RPX SaaS to do OpenID. The key result of this is URL describing the logged in user. The app itself is heavily Javascript and I'm planning on using a REST api to communicate with the backend for database persistence and spatial processing.
The security requirements on this application aren't big. I want to know which user is making a request. I don't believe I need to use SSL to be confidential about the data and I don't want the overhead of running SSL.
I'm using Spring and would like to use Spring Security (Acegi) if possible but I'm not wedded to that idea.
Options:
Return the OpenID URL to the Javascript app, use this to retrieve the list of resources for the user and then retrieve/save/etc those resources by id.
Create a session table which connects the OpenID URL with a random session token. Return the token to the Javascript app which must then return the token with every subsequent request.
Use the session from option 2 as the Consumer Token, etc for OAuth. Initially, the session would be sent to the app using PKI encryption.
Rely on J2EE HTTP Session.
Of these options I'm leaning towards option 2. Hijacking the session would be difficult as the attacker would have to guess the session id and I don't believe the application requires protection from sniffing. Option 3 is essentially the same as option 2 but the session id isn't available for sniffing. Option 4 puts the OpenID URL into the server's memory and causes all the scalability problems REST is designed to avoid.
I'm grateful for any discussion on this.
So, 2 years 3 months later I can answer my own question. I implemented this for my personal project and I have separately implemented it for my employer.
Plugging into Spring Security is the best way to go. You can choose to use the pre-authenticated flow but you may find the CasAuthenticationFilter (and CasAuthenticationEntryPoint) work better as they have most of the flow you need.