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 07:01:41 GMT
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<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