[
https://issues.apache.org/activemq/browse/CAMEL-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Przemyslaw Budzik updated CAMEL-1211:
-------------------------------------
Attachment: info_to_debug.patch
> camel-restlet security extension
> --------------------------------
>
> Key: CAMEL-1211
> URL: https://issues.apache.org/activemq/browse/CAMEL-1211
> Project: Apache Camel
> Issue Type: Improvement
> Components: camel-core, camel-restlet
> Affects Versions: 1.5.1, 2.0.0
> Reporter: Przemyslaw Budzik
> Priority: Minor
> Attachments: info_to_debug.patch
>
>
> Now we have basic http auth. Quick shot is adding digest as it is supported
> by Restlet, but I have something more in mind. As I'm using token based auth
> and for me http auth is not suitable (pushing credentials back and forth all
> the time etc). How about a pattern where from one endpoint you can consume a
> ticket/token/sessionId and you can use it as a header to authenticate? As now
> the realm is to keep login and pass and it could be something like a bean
> that can validate the token. Of course that data would not be static so it is
> more about a callback (eg. getTokens()) than a static map/list. And finally
> as we have the uri we can resolve an "operation" and do authorization (so
> uri+method is the target). I mean in my project I have processor that does
> stuff like that and it would be cool to have all those things in one place in
> consumer (and provide only data and have skeletal logic under the hood).
> Now the question is if my idea makes sense and if so what are your
> suggestions on how to implement that w/o reinventing the wheel (and not using
> ACEGI ;-))
> Btw, Claus, William - logs about attaching/detaching restlets are at info
> level and it's kind of spamming if there are say 20 endpoints... Maybe it
> should be at debug?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
