camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Krasser <...@martin-krasser.de>
Subject Re: [HEADS UP] Camel Security
Date Thu, 08 Apr 2010 05:11:30 GMT
+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<willem.jiang@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<willem.jiang@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
>>
>>      
>
>
>    


Mime
View raw message