You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Willem Jiang <wi...@gmail.com> on 2010/04/07 15:25:12 UTC
[HEADS UP] Camel Security
Hi,
I just added a design notes[1] for the Camel Security which shows a
rough design of Camel Security API, which just leverage the Camel Policy
API to delegate the access control to the AuthorizationPolicy. In this
way we can plugin different AuthoriztionPolicy implementation based on
different security framework easily.
For the authentication, as camel doesn't have any GUI or other interface
to type the user name and password. We just store the authentication
instance into the exchange property and let the camel client to deal
with authentication work. In the feature we could add some
authentication support on the camel-servlet, camel-jetty consumer.
Any thought?
[1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
Willem
Re: [HEADS UP] Camel Security
Posted by Johan Edstrom <jo...@opennms.org>.
+1!
On Apr 7, 2010, at 7:25 AM, Willem Jiang wrote:
> http://cwiki.apache.org/confluence/display/CAMEL/Camel+Securit
Johan Edstrom
joed@opennms.org
They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
Benjamin Franklin, Historical Review of Pennsylvania, 1759
Re: [HEADS UP] Camel Security
Posted by Willem Jiang <wi...@gmail.com>.
Hi Martin,
Thanks for your explanation. After going through the Java doc again, the
Subject object should be the best choice.
Willem
Martin Krasser wrote:
> Authenticated principals are usually represented as
> javax.security.auth.Subject. This is what what JAAS requires and what
> most containers. A Subject then contains a set of Principal instances
> e.g. representing the user and its roles (or whatever ... this is
> usually application-specific).
>
> Willem Jiang schrieb:
>> Yeah, we could use Principle to store the authentication.
>>
>> Willem
>>
>> Martin Krasser wrote:
>>> +1 for leveraging the standard Java security APIs for authentication.
>>> This would also fit nicely with authentication mechanisms of JEE
>>> containers.
>>>
>>> Am 08.04.2010 07:03, schrieb Claus Ibsen:
>>>> On Thu, Apr 8, 2010 at 6:40 AM, Willem
>>>> Jiang<wi...@gmail.com> wrote:
>>>>
>>>>> Hi Claus,
>>>>>
>>>>> My comments are in the mail.
>>>>>
>>>>> Claus Ibsen wrote:
>>>>>
>>>>>> Hi Willem
>>>>>>
>>>>>> Looks great.
>>>>>>
>>>>>> Only think is that I wonder if introducing another schema
>>>>>> (spring/security) in Camel.
>>>>>>
>>>>>> Is it entirely spring-security based? Maybe the schema should be
>>>>>> named
>>>>>> to reflect this to avoid it being a _general_ security schema for
>>>>>> Camel.
>>>>>> etc name it (spring/spring-security) if it based 100% on the Spring
>>>>>> Security Framework only.
>>>>>>
>>>>> The new schema is based on spring-security to make the user
>>>>> configure the
>>>>> AuthorizationPolicy easily. I don't want to introduce a
>>>>> _general_security
>>>>> schema for camel at this time.
>>>>>
>>>>>
>>>>>> I assume if the Exchange is denied then a CamelAuthorizationException
>>>>>> is thrown. And this exception is from camel-core? eg org.apache.camel
>>>>>> package.
>>>>>> Then each different camel security component can create their own sub
>>>>>> class of this exception if they need specialized details in their
>>>>>> exception.
>>>>>>
>>>>> +1
>>>>>
>>>>>>
>>>>>>> To support Spring Security framework we can store the authentication
>>>>>>> instance of Spring security with Exchange.AUTHENTICATION
>>>>>>> as the key into the exchange property, if we want to support other
>>>>>>> security framework, we could also store other framework's
>>>>>>> authentication
>>>>>>> information into the exchange .
>>>>>>>
>>>>>> I wonder if we should store this in a Camel standard way? eg have the
>>>>>> information stored as some kind of interface which the different
>>>>>> security components
>>>>>> can adapt and understand? If we want to use the same key for all
>>>>>> security components, then I think we need a common type it must be
>>>>>> stored as.
>>>>>>
>>>>> How about introduce a common Authentication interface, and we could
>>>>> let the
>>>>> different security component implement it themselves, and provides
>>>>> customer
>>>>> converters to turn the common Authentication instance into the
>>>>> Authentication instance which can be used in the security component.
>>>>>
>>>>>
>>>> I wonder if it should leverage the standard security API from JDK 1.5
>>>> http://java.sun.com/j2se/1.5.0/docs/api/index.html
>>>>
>>>> There is a java.security and javax.security packages.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang<wi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just added a design notes[1] for the Camel Security which shows
>>>>>>> a rough
>>>>>>> design of Camel Security API, which just leverage the Camel
>>>>>>> Policy API to
>>>>>>> delegate the access control to the AuthorizationPolicy. In this
>>>>>>> way we
>>>>>>> can
>>>>>>> plugin different AuthoriztionPolicy implementation based on
>>>>>>> different
>>>>>>> security framework easily.
>>>>>>>
>>>>>>> For the authentication, as camel doesn't have any GUI or other
>>>>>>> interface
>>>>>>> to
>>>>>>> type the user name and password. We just store the authentication
>>>>>>> instance
>>>>>>> into the exchange property and let the camel client to deal with
>>>>>>> authentication work. In the feature we could add some authentication
>>>>>>> support
>>>>>>> on the camel-servlet, camel-jetty consumer.
>>>>>>>
>>>>>>> Any thought?
>>>>>>>
>>>>>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>>>>>
>>>>>>> Willem
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
Re: [HEADS UP] Camel Security
Posted by Martin Krasser <de...@martin-krasser.de>.
Authenticated principals are usually represented as
javax.security.auth.Subject. This is what what JAAS requires and what
most containers. A Subject then contains a set of Principal instances
e.g. representing the user and its roles (or whatever ... this is
usually application-specific).
Willem Jiang schrieb:
> Yeah, we could use Principle to store the authentication.
>
> Willem
>
> Martin Krasser wrote:
>> +1 for leveraging the standard Java security APIs for authentication.
>> This would also fit nicely with authentication mechanisms of JEE
>> containers.
>>
>> Am 08.04.2010 07:03, schrieb Claus Ibsen:
>>> On Thu, Apr 8, 2010 at 6:40 AM, Willem
>>> Jiang<wi...@gmail.com> wrote:
>>>
>>>> Hi Claus,
>>>>
>>>> My comments are in the mail.
>>>>
>>>> Claus Ibsen wrote:
>>>>
>>>>> Hi Willem
>>>>>
>>>>> Looks great.
>>>>>
>>>>> Only think is that I wonder if introducing another schema
>>>>> (spring/security) in Camel.
>>>>>
>>>>> Is it entirely spring-security based? Maybe the schema should be
>>>>> named
>>>>> to reflect this to avoid it being a _general_ security schema for
>>>>> Camel.
>>>>> etc name it (spring/spring-security) if it based 100% on the Spring
>>>>> Security Framework only.
>>>>>
>>>> The new schema is based on spring-security to make the user
>>>> configure the
>>>> AuthorizationPolicy easily. I don't want to introduce a
>>>> _general_security
>>>> schema for camel at this time.
>>>>
>>>>
>>>>> I assume if the Exchange is denied then a CamelAuthorizationException
>>>>> is thrown. And this exception is from camel-core? eg org.apache.camel
>>>>> package.
>>>>> Then each different camel security component can create their own sub
>>>>> class of this exception if they need specialized details in their
>>>>> exception.
>>>>>
>>>> +1
>>>>
>>>>>
>>>>>> To support Spring Security framework we can store the authentication
>>>>>> instance of Spring security with Exchange.AUTHENTICATION
>>>>>> as the key into the exchange property, if we want to support other
>>>>>> security framework, we could also store other framework's
>>>>>> authentication
>>>>>> information into the exchange .
>>>>>>
>>>>> I wonder if we should store this in a Camel standard way? eg have the
>>>>> information stored as some kind of interface which the different
>>>>> security components
>>>>> can adapt and understand? If we want to use the same key for all
>>>>> security components, then I think we need a common type it must be
>>>>> stored as.
>>>>>
>>>> How about introduce a common Authentication interface, and we could
>>>> let the
>>>> different security component implement it themselves, and provides
>>>> customer
>>>> converters to turn the common Authentication instance into the
>>>> Authentication instance which can be used in the security component.
>>>>
>>>>
>>> I wonder if it should leverage the standard security API from JDK 1.5
>>> http://java.sun.com/j2se/1.5.0/docs/api/index.html
>>>
>>> There is a java.security and javax.security packages.
>>>
>>>
>>>
>>>
>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang<wi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just added a design notes[1] for the Camel Security which shows
>>>>>> a rough
>>>>>> design of Camel Security API, which just leverage the Camel
>>>>>> Policy API to
>>>>>> delegate the access control to the AuthorizationPolicy. In this
>>>>>> way we
>>>>>> can
>>>>>> plugin different AuthoriztionPolicy implementation based on
>>>>>> different
>>>>>> security framework easily.
>>>>>>
>>>>>> For the authentication, as camel doesn't have any GUI or other
>>>>>> interface
>>>>>> to
>>>>>> type the user name and password. We just store the authentication
>>>>>> instance
>>>>>> into the exchange property and let the camel client to deal with
>>>>>> authentication work. In the feature we could add some authentication
>>>>>> support
>>>>>> on the camel-servlet, camel-jetty consumer.
>>>>>>
>>>>>> Any thought?
>>>>>>
>>>>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> Willem
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
Re: [HEADS UP] Camel Security
Posted by Willem Jiang <wi...@gmail.com>.
Yeah, we could use Principle to store the authentication.
Willem
Martin Krasser wrote:
> +1 for leveraging the standard Java security APIs for authentication.
> This would also fit nicely with authentication mechanisms of JEE
> containers.
>
> Am 08.04.2010 07:03, schrieb Claus Ibsen:
>> On Thu, Apr 8, 2010 at 6:40 AM, Willem Jiang<wi...@gmail.com>
>> wrote:
>>
>>> Hi Claus,
>>>
>>> My comments are in the mail.
>>>
>>> Claus Ibsen wrote:
>>>
>>>> Hi Willem
>>>>
>>>> Looks great.
>>>>
>>>> Only think is that I wonder if introducing another schema
>>>> (spring/security) in Camel.
>>>>
>>>> Is it entirely spring-security based? Maybe the schema should be named
>>>> to reflect this to avoid it being a _general_ security schema for
>>>> Camel.
>>>> etc name it (spring/spring-security) if it based 100% on the Spring
>>>> Security Framework only.
>>>>
>>> The new schema is based on spring-security to make the user configure
>>> the
>>> AuthorizationPolicy easily. I don't want to introduce a
>>> _general_security
>>> schema for camel at this time.
>>>
>>>
>>>> I assume if the Exchange is denied then a CamelAuthorizationException
>>>> is thrown. And this exception is from camel-core? eg org.apache.camel
>>>> package.
>>>> Then each different camel security component can create their own sub
>>>> class of this exception if they need specialized details in their
>>>> exception.
>>>>
>>> +1
>>>
>>>>
>>>>> To support Spring Security framework we can store the authentication
>>>>> instance of Spring security with Exchange.AUTHENTICATION
>>>>> as the key into the exchange property, if we want to support other
>>>>> security framework, we could also store other framework's
>>>>> authentication
>>>>> information into the exchange .
>>>>>
>>>> I wonder if we should store this in a Camel standard way? eg have the
>>>> information stored as some kind of interface which the different
>>>> security components
>>>> can adapt and understand? If we want to use the same key for all
>>>> security components, then I think we need a common type it must be
>>>> stored as.
>>>>
>>> How about introduce a common Authentication interface, and we could
>>> let the
>>> different security component implement it themselves, and provides
>>> customer
>>> converters to turn the common Authentication instance into the
>>> Authentication instance which can be used in the security component.
>>>
>>>
>> I wonder if it should leverage the standard security API from JDK 1.5
>> http://java.sun.com/j2se/1.5.0/docs/api/index.html
>>
>> There is a java.security and javax.security packages.
>>
>>
>>
>>
>>
>>>>
>>>>
>>>> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang<wi...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I just added a design notes[1] for the Camel Security which shows a
>>>>> rough
>>>>> design of Camel Security API, which just leverage the Camel Policy
>>>>> API to
>>>>> delegate the access control to the AuthorizationPolicy. In this way we
>>>>> can
>>>>> plugin different AuthoriztionPolicy implementation based on different
>>>>> security framework easily.
>>>>>
>>>>> For the authentication, as camel doesn't have any GUI or other
>>>>> interface
>>>>> to
>>>>> type the user name and password. We just store the authentication
>>>>> instance
>>>>> into the exchange property and let the camel client to deal with
>>>>> authentication work. In the feature we could add some authentication
>>>>> support
>>>>> on the camel-servlet, camel-jetty consumer.
>>>>>
>>>>> Any thought?
>>>>>
>>>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> Willem
>>>
>>>
>>
>>
>>
>
>
Re: [HEADS UP] Camel Security
Posted by Martin Krasser <de...@martin-krasser.de>.
+1 for leveraging the standard Java security APIs for authentication.
This would also fit nicely with authentication mechanisms of JEE containers.
Am 08.04.2010 07:03, schrieb Claus Ibsen:
> On Thu, Apr 8, 2010 at 6:40 AM, Willem Jiang<wi...@gmail.com> wrote:
>
>> Hi Claus,
>>
>> My comments are in the mail.
>>
>> Claus Ibsen wrote:
>>
>>> Hi Willem
>>>
>>> Looks great.
>>>
>>> Only think is that I wonder if introducing another schema
>>> (spring/security) in Camel.
>>>
>>> Is it entirely spring-security based? Maybe the schema should be named
>>> to reflect this to avoid it being a _general_ security schema for
>>> Camel.
>>> etc name it (spring/spring-security) if it based 100% on the Spring
>>> Security Framework only.
>>>
>> The new schema is based on spring-security to make the user configure the
>> AuthorizationPolicy easily. I don't want to introduce a _general_security
>> schema for camel at this time.
>>
>>
>>> I assume if the Exchange is denied then a CamelAuthorizationException
>>> is thrown. And this exception is from camel-core? eg org.apache.camel
>>> package.
>>> Then each different camel security component can create their own sub
>>> class of this exception if they need specialized details in their
>>> exception.
>>>
>> +1
>>
>>>
>>>> To support Spring Security framework we can store the authentication
>>>> instance of Spring security with Exchange.AUTHENTICATION
>>>> as the key into the exchange property, if we want to support other
>>>> security framework, we could also store other framework's authentication
>>>> information into the exchange .
>>>>
>>> I wonder if we should store this in a Camel standard way? eg have the
>>> information stored as some kind of interface which the different
>>> security components
>>> can adapt and understand? If we want to use the same key for all
>>> security components, then I think we need a common type it must be
>>> stored as.
>>>
>> How about introduce a common Authentication interface, and we could let the
>> different security component implement it themselves, and provides customer
>> converters to turn the common Authentication instance into the
>> Authentication instance which can be used in the security component.
>>
>>
> I wonder if it should leverage the standard security API from JDK 1.5
> http://java.sun.com/j2se/1.5.0/docs/api/index.html
>
> There is a java.security and javax.security packages.
>
>
>
>
>
>>>
>>>
>>> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang<wi...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just added a design notes[1] for the Camel Security which shows a rough
>>>> design of Camel Security API, which just leverage the Camel Policy API to
>>>> delegate the access control to the AuthorizationPolicy. In this way we
>>>> can
>>>> plugin different AuthoriztionPolicy implementation based on different
>>>> security framework easily.
>>>>
>>>> For the authentication, as camel doesn't have any GUI or other interface
>>>> to
>>>> type the user name and password. We just store the authentication
>>>> instance
>>>> into the exchange property and let the camel client to deal with
>>>> authentication work. In the feature we could add some authentication
>>>> support
>>>> on the camel-servlet, camel-jetty consumer.
>>>>
>>>> Any thought?
>>>>
>>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>>
>>>> Willem
>>>>
>>>>
>>>
>>>
>>>
>> Willem
>>
>>
>
>
>
Re: [HEADS UP] Camel Security
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Apr 8, 2010 at 6:40 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus,
>
> My comments are in the mail.
>
> Claus Ibsen wrote:
>>
>> Hi Willem
>>
>> Looks great.
>>
>> Only think is that I wonder if introducing another schema
>> (spring/security) in Camel.
>>
>> Is it entirely spring-security based? Maybe the schema should be named
>> to reflect this to avoid it being a _general_ security schema for
>> Camel.
>> etc name it (spring/spring-security) if it based 100% on the Spring
>> Security Framework only.
>
> The new schema is based on spring-security to make the user configure the
> AuthorizationPolicy easily. I don't want to introduce a _general_security
> schema for camel at this time.
>
>>
>> I assume if the Exchange is denied then a CamelAuthorizationException
>> is thrown. And this exception is from camel-core? eg org.apache.camel
>> package.
>> Then each different camel security component can create their own sub
>> class of this exception if they need specialized details in their
>> exception.
>
> +1
>>
>>> To support Spring Security framework we can store the authentication
>>> instance of Spring security with Exchange.AUTHENTICATION
>>> as the key into the exchange property, if we want to support other
>>> security framework, we could also store other framework's authentication
>>> information into the exchange .
>>
>> I wonder if we should store this in a Camel standard way? eg have the
>> information stored as some kind of interface which the different
>> security components
>> can adapt and understand? If we want to use the same key for all
>> security components, then I think we need a common type it must be
>> stored as.
>
> How about introduce a common Authentication interface, and we could let the
> different security component implement it themselves, and provides customer
> converters to turn the common Authentication instance into the
> Authentication instance which can be used in the security component.
>
I wonder if it should leverage the standard security API from JDK 1.5
http://java.sun.com/j2se/1.5.0/docs/api/index.html
There is a java.security and javax.security packages.
>>
>>
>>
>> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang <wi...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I just added a design notes[1] for the Camel Security which shows a rough
>>> design of Camel Security API, which just leverage the Camel Policy API to
>>> delegate the access control to the AuthorizationPolicy. In this way we
>>> can
>>> plugin different AuthoriztionPolicy implementation based on different
>>> security framework easily.
>>>
>>> For the authentication, as camel doesn't have any GUI or other interface
>>> to
>>> type the user name and password. We just store the authentication
>>> instance
>>> into the exchange property and let the camel client to deal with
>>> authentication work. In the feature we could add some authentication
>>> support
>>> on the camel-servlet, camel-jetty consumer.
>>>
>>> Any thought?
>>>
>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>
>>> Willem
>>>
>>
>>
>>
>
> Willem
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [HEADS UP] Camel Security
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
My comments are in the mail.
Claus Ibsen wrote:
> Hi Willem
>
> Looks great.
>
> Only think is that I wonder if introducing another schema
> (spring/security) in Camel.
>
> Is it entirely spring-security based? Maybe the schema should be named
> to reflect this to avoid it being a _general_ security schema for
> Camel.
> etc name it (spring/spring-security) if it based 100% on the Spring
> Security Framework only.
The new schema is based on spring-security to make the user configure
the AuthorizationPolicy easily. I don't want to introduce a
_general_security schema for camel at this time.
>
> I assume if the Exchange is denied then a CamelAuthorizationException
> is thrown. And this exception is from camel-core? eg org.apache.camel
> package.
> Then each different camel security component can create their own sub
> class of this exception if they need specialized details in their
> exception.
+1
>
>> To support Spring Security framework we can store the authentication instance of Spring security with Exchange.AUTHENTICATION
>> as the key into the exchange property, if we want to support other security framework, we could also store other framework's authentication
>> information into the exchange .
>
> I wonder if we should store this in a Camel standard way? eg have the
> information stored as some kind of interface which the different
> security components
> can adapt and understand? If we want to use the same key for all
> security components, then I think we need a common type it must be
> stored as.
How about introduce a common Authentication interface, and we could let
the different security component implement it themselves, and provides
customer converters to turn the common Authentication instance into the
Authentication instance which can be used in the security component.
>
>
>
> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang <wi...@gmail.com> wrote:
>> Hi,
>>
>> I just added a design notes[1] for the Camel Security which shows a rough
>> design of Camel Security API, which just leverage the Camel Policy API to
>> delegate the access control to the AuthorizationPolicy. In this way we can
>> plugin different AuthoriztionPolicy implementation based on different
>> security framework easily.
>>
>> For the authentication, as camel doesn't have any GUI or other interface to
>> type the user name and password. We just store the authentication instance
>> into the exchange property and let the camel client to deal with
>> authentication work. In the feature we could add some authentication support
>> on the camel-servlet, camel-jetty consumer.
>>
>> Any thought?
>>
>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>
>> Willem
>>
>
>
>
Willem
Re: [HEADS UP] Camel Security
Posted by Willem Jiang <wi...@gmail.com>.
Just one more thing about using the Spring Security.
Current Spring Security released 3.0.2 which uses the Spring 3.x, and
Spring Security 2.0.5 which can be used with Spring 2.x and Spring 3.x.
To support the user of Spring 2.x and Spring 3.x at the same time , I'm
planing to use the Spring Security 2.0.5, but it will cause some plain
when we upgrade to use Spring Security 3.x.
If we are using Spring Security 3.x, that could be a good reason to let
people to use Spring 3.x in the feature.
Any thought?
Willem
> On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang <wi...@gmail.com> wrote:
>> Hi,
>>
>> I just added a design notes[1] for the Camel Security which shows a rough
>> design of Camel Security API, which just leverage the Camel Policy API to
>> delegate the access control to the AuthorizationPolicy. In this way we can
>> plugin different AuthoriztionPolicy implementation based on different
>> security framework easily.
>>
>> For the authentication, as camel doesn't have any GUI or other interface to
>> type the user name and password. We just store the authentication instance
>> into the exchange property and let the camel client to deal with
>> authentication work. In the feature we could add some authentication support
>> on the camel-servlet, camel-jetty consumer.
>>
>> Any thought?
>>
>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>
>> Willem
>>
>
>
>
Re: [HEADS UP] Camel Security
Posted by Claus Ibsen <cl...@gmail.com>.
Hi Willem
Looks great.
Only think is that I wonder if introducing another schema
(spring/security) in Camel.
Is it entirely spring-security based? Maybe the schema should be named
to reflect this to avoid it being a _general_ security schema for
Camel.
etc name it (spring/spring-security) if it based 100% on the Spring
Security Framework only.
I assume if the Exchange is denied then a CamelAuthorizationException
is thrown. And this exception is from camel-core? eg org.apache.camel
package.
Then each different camel security component can create their own sub
class of this exception if they need specialized details in their
exception.
> To support Spring Security framework we can store the authentication instance of Spring security with Exchange.AUTHENTICATION
> as the key into the exchange property, if we want to support other security framework, we could also store other framework's authentication
> information into the exchange .
I wonder if we should store this in a Camel standard way? eg have the
information stored as some kind of interface which the different
security components
can adapt and understand? If we want to use the same key for all
security components, then I think we need a common type it must be
stored as.
On Wed, Apr 7, 2010 at 3:25 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi,
>
> I just added a design notes[1] for the Camel Security which shows a rough
> design of Camel Security API, which just leverage the Camel Policy API to
> delegate the access control to the AuthorizationPolicy. In this way we can
> plugin different AuthoriztionPolicy implementation based on different
> security framework easily.
>
> For the authentication, as camel doesn't have any GUI or other interface to
> type the user name and password. We just store the authentication instance
> into the exchange property and let the camel client to deal with
> authentication work. In the feature we could add some authentication support
> on the camel-servlet, camel-jetty consumer.
>
> Any thought?
>
> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>
> Willem
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [HEADS UP] Camel Security
Posted by Willem Jiang <wi...@gmail.com>.
Martin Krasser wrote:
> Am 08.04.2010 07:18, schrieb Claus Ibsen:
>> On Thu, Apr 8, 2010 at 7:09 AM, Martin Krasser<de...@martin-krasser.de>
>> wrote:
>>
>>> Hi Willem,
>>>
>>> I like that.
>>>
>>> One additional thing I could imagine is to have an AOP style for
>>> applying
>>> policies to endpoints. For example, instead of writing a policy()
>>> directly
>>> into the route one could have:
>>>
>>> // access control DSL (AOP style)
>>> enforce("adminPolicy").at("direct:myEndpoint")
>>>
>>> // route to which the access control DSL applies
>>> from(...).process(...).to("direct:myEndpoint")
>>>
>>> What do you think?
>>>
>>>
>> I think we should do this in 2 steps
>> 1) As currently without DSL changes but getting the
>> camel-spring-security component and all the other pieces into place
>>
>> 2) In a future release introduce a nice DSL for easier setting up
>> security in the routes, eg to separate it out from the route logic, as
>> Martin have suggested.
>> The DSL needs to be intuitive and work well for both Java DSL and
>> Spring XML (and to be added for Scala DSL as well)
>>
>
> +1
>
In the design note, I add a TODO list for configure the Authorization
policy on the endpoint with regular express, which is much like the
martin showed.
>>
>>
>>
>>> Am 07.04.2010 15:25, schrieb Willem Jiang:
>>>
>>>> Hi,
>>>>
>>>> I just added a design notes[1] for the Camel Security which shows a
>>>> rough
>>>> design of Camel Security API, which just leverage the Camel Policy
>>>> API to
>>>> delegate the access control to the AuthorizationPolicy. In this way
>>>> we can
>>>> plugin different AuthoriztionPolicy implementation based on different
>>>> security framework easily.
>>>>
>>>> For the authentication, as camel doesn't have any GUI or other
>>>> interface
>>>> to type the user name and password. We just store the authentication
>>>> instance into the exchange property and let the camel client to deal
>>>> with
>>>> authentication work. In the feature we could add some authentication
>>>> support
>>>> on the camel-servlet, camel-jetty consumer.
>>>>
>>>> Any thought?
>>>>
>>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>>
>>>> Willem
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: [HEADS UP] Camel Security
Posted by Martin Krasser <de...@martin-krasser.de>.
Am 08.04.2010 07:18, schrieb Claus Ibsen:
> On Thu, Apr 8, 2010 at 7:09 AM, Martin Krasser<de...@martin-krasser.de> wrote:
>
>> Hi Willem,
>>
>> I like that.
>>
>> One additional thing I could imagine is to have an AOP style for applying
>> policies to endpoints. For example, instead of writing a policy() directly
>> into the route one could have:
>>
>> // access control DSL (AOP style)
>> enforce("adminPolicy").at("direct:myEndpoint")
>>
>> // route to which the access control DSL applies
>> from(...).process(...).to("direct:myEndpoint")
>>
>> What do you think?
>>
>>
> I think we should do this in 2 steps
> 1) As currently without DSL changes but getting the
> camel-spring-security component and all the other pieces into place
>
> 2) In a future release introduce a nice DSL for easier setting up
> security in the routes, eg to separate it out from the route logic, as
> Martin have suggested.
> The DSL needs to be intuitive and work well for both Java DSL and
> Spring XML (and to be added for Scala DSL as well)
>
+1
>
>
>
>> Am 07.04.2010 15:25, schrieb Willem Jiang:
>>
>>> Hi,
>>>
>>> I just added a design notes[1] for the Camel Security which shows a rough
>>> design of Camel Security API, which just leverage the Camel Policy API to
>>> delegate the access control to the AuthorizationPolicy. In this way we can
>>> plugin different AuthoriztionPolicy implementation based on different
>>> security framework easily.
>>>
>>> For the authentication, as camel doesn't have any GUI or other interface
>>> to type the user name and password. We just store the authentication
>>> instance into the exchange property and let the camel client to deal with
>>> authentication work. In the feature we could add some authentication support
>>> on the camel-servlet, camel-jetty consumer.
>>>
>>> Any thought?
>>>
>>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>>
>>> Willem
>>>
>>
>>
>
>
>
Re: [HEADS UP] Camel Security
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Apr 8, 2010 at 7:09 AM, Martin Krasser <de...@martin-krasser.de> wrote:
> Hi Willem,
>
> I like that.
>
> One additional thing I could imagine is to have an AOP style for applying
> policies to endpoints. For example, instead of writing a policy() directly
> into the route one could have:
>
> // access control DSL (AOP style)
> enforce("adminPolicy").at("direct:myEndpoint")
>
> // route to which the access control DSL applies
> from(...).process(...).to("direct:myEndpoint")
>
> What do you think?
>
I think we should do this in 2 steps
1) As currently without DSL changes but getting the
camel-spring-security component and all the other pieces into place
2) In a future release introduce a nice DSL for easier setting up
security in the routes, eg to separate it out from the route logic, as
Martin have suggested.
The DSL needs to be intuitive and work well for both Java DSL and
Spring XML (and to be added for Scala DSL as well)
> Am 07.04.2010 15:25, schrieb Willem Jiang:
>>
>> Hi,
>>
>> I just added a design notes[1] for the Camel Security which shows a rough
>> design of Camel Security API, which just leverage the Camel Policy API to
>> delegate the access control to the AuthorizationPolicy. In this way we can
>> plugin different AuthoriztionPolicy implementation based on different
>> security framework easily.
>>
>> For the authentication, as camel doesn't have any GUI or other interface
>> to type the user name and password. We just store the authentication
>> instance into the exchange property and let the camel client to deal with
>> authentication work. In the feature we could add some authentication support
>> on the camel-servlet, camel-jetty consumer.
>>
>> Any thought?
>>
>> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>>
>> Willem
>
>
--
Claus Ibsen
Apache Camel Committer
Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: [HEADS UP] Camel Security
Posted by Martin Krasser <de...@martin-krasser.de>.
Hi Willem,
I like that.
One additional thing I could imagine is to have an AOP style for
applying policies to endpoints. For example, instead of writing a
policy() directly into the route one could have:
// access control DSL (AOP style)
enforce("adminPolicy").at("direct:myEndpoint")
// route to which the access control DSL applies
from(...).process(...).to("direct:myEndpoint")
What do you think?
Am 07.04.2010 15:25, schrieb Willem Jiang:
> Hi,
>
> I just added a design notes[1] for the Camel Security which shows a
> rough design of Camel Security API, which just leverage the Camel
> Policy API to delegate the access control to the AuthorizationPolicy.
> In this way we can plugin different AuthoriztionPolicy implementation
> based on different security framework easily.
>
> For the authentication, as camel doesn't have any GUI or other
> interface to type the user name and password. We just store the
> authentication instance into the exchange property and let the camel
> client to deal with authentication work. In the feature we could add
> some authentication support on the camel-servlet, camel-jetty consumer.
>
> Any thought?
>
> [1]http://cwiki.apache.org/confluence/display/CAMEL/Camel+Security
>
> Willem