Add support for OAuth authentication #112
Comments
akka-ci
added
help wanted
|
+1 |
|
+1 this would be spectacular! |
|
+1 |
|
I've been poking at this a little. It seems like https://github.com/akka/akka/blob/f71dfbaeccf08f08b8fcef3d1cfd46c6875c26a9/akka-http-core/src/main/java/akka/http/javadsl/model/headers/HttpCredentials.java#L26-28 might be a good idea in some regards and a bad idea in others. For instance, what about OAuth1? 1a? JWT? Where does the list end? What happens when someone wants Kerberos? Does Akka rev for that? Apologies if this sounds too direct. I think it would be great if HTTP supported all this good stuff, just not sure if it's possible (there's always another protocol) and then how to best manage it when there is another one. I'm becoming a bigger fan of kerberized services by the day -- there's always a low-intensity password attack going on against my IMAP services, for instance -- but the model is quite a bit different than other authentication schemes. |
|
My current take is to keep functionality as much out of akka-http as possible but provide reasonable infrastructure to make third-party addons simple. Concretely, I would rather accept parsers/renderers for well-known and well-spec'd headers (a cookie anyone?) than potentially security relevant code implementing semantics for an authentication scheme that needs to be maintained inside of akka. |
|
That's more or less what I was thinking, I just wonder if it might make more sense to have per-pool or per-connection transform hooks that security providers could loop in through. So for instance, once a security provider was specified for a connection, all requests over that connection would automatically use that provider. For their part, providers might insert stream elements to indicate their actions and otherwise abstract the low level details. In doing so, Akka can stay out of the business of "well known headers" (where does the toolkit draw the line?) and leave them as CustomHeader. The app, knowing that the provider is inserting events, can pattern match against them when it needs to know. Thoughts? |
|
Hmm, http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/stream-customize.html seems to indicate that a Stage can't generate multiple messages and I'm guessing it applies here. I do think it's a nice pattern though, that a configured provider (security or otherwise) can report context changes occurring in a pipeline by inserting messages in the stream like that. |
|
This is not true, the "Duplicator" example shows how to generate multiple messages. Most of the built-in Akka combinators use stages, see: https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/impl/fusing/Ops.scala Or you meant something different? |
|
Thanks for the correction, I got distracted with the warning at the top of the page. |
|
Linked as stretch goal of high level client, help here is certainly welcome as we won't work on it for now. |
|
I built a PushPull that does it, works great. I had hoped to clean it up and submit it, just forgot since there's now a project out that contains some of this. Maybe could be closed on account of that project? |
|
Which project specifically? OAuth is one of the few things that a bit more built-in support would be good to hare in Akka HTTP I think, as it's so "everywhere". |
|
Yes agreed. It's 7am here, just laying in bed typing from phone. I'll look for it later and update accordingly. Maybe it makes sense to contribute what I have after all. |
|
Would be fun, thanks in advance! |
ktoso
added
1 - triaged
jrudolph
added
t:client
Wednesday Feb 11, 2015 at 13:59 GMT
Originally opened as akka/akka#16857
See spray/spray#1007 and the previous unmerged PR spray/spray#372.
/cc @sirthias
The text was updated successfully, but these errors were encountered: