[jboss-dev] pluggable auth-method
Anil Saldhana
Anil.Saldhana at redhat.com
Thu Jul 15 10:46:55 EDT 2010
Sergey,
extend Tomcat AuthenticatorBase class for your authenticator. It
should have available in the catalina jar.
Cheers.
On 07/15/2010 09:20 AM, Sergey Beryozkin wrote:
> Hi Anil
>
>
> ----- "Anil Saldhana"<Anil.Saldhana at redhat.com> wrote:
>
>
>> The login modules happen late in the container security sequence and
>> have limited access to the network message etc. They can only say
>> yes/no to authentication. But they cannot do some of the redirects or
>>
>> other extra steps that are needed in mechanisms outside of the servlet
>>
>> spec mechanisms (form, client-cert, basic,digest). SAML,
>> OpenID/OAuth
>> etc may need access to the network message (http message) and may have
>>
>> to redirect the request to an external identity provider. In these
>> situations, you do container integration (in the case of tomcat, it is
>>
>> via authenticators).
>>
>> Ideally, you should be doing JSR-196 which will provide you the
>> pluggable server authentication modules and can stack modules just as
>>
>> you do with login modules.
>>
>> We have support for JSR-196 in AS6 which needs to be taken further
>> before EE6 certification.
>> http://anil-identity.blogspot.com/search/label/jsr-196
>>
>>
> thanks for all the info, I will experiment with Athenticators, no redirection will be needed in cases where they should
> enforce that a given OAuth consumer is a valid one, but I'd like to try them too...
>
> How to figure out which catalina/tomcat dependency should be used for writing a custom Authenticator to be used in JBossAS 6.0 deployments ?
>
> thanks, Sergey
>
>
>
>> On 07/14/2010 11:17 AM, Sergey Beryozkin wrote:
>>
>>> Hi
>>>
>>>
>>>
>>>> For OAuth there are a few issues:
>>>>
>>>> 1. It has specific headers.
>>>> 2. You create "secrets" on the fly which are used to authenticate
>>>>
>> and
>>
>>>> authorize requests.
>>>>
>>>>
>>>>
>>> Regarding 2: This is just one approach which the RestEasy
>>>
>> oauth-push-messaging takes, but one can imagine
>>
>>> the administrator registering the OAuth consumers representing say
>>>
>> messaging services in advance.
>>
>>>
>>>
>>>
>>>> Maybe its best to first iterate on an Authenticator, then move
>>>>
>> logic
>>
>>>> up
>>>> the stack once you get a prototype going? I don't know how Sergey
>>>> likes
>>>> to work :)
>>>>
>>>>
>>> Well, my own problem so far is that I doubt the necessity of
>>>
>> introducing a role-based
>>
>>> control access in a push-messaging case given the way the current
>>>
>> solution works.
>>
>>> Specifically, a subscriber needs to grant the messaging service a
>>>
>> permission to access a destination URI using a (domain) admin-level
>> invocation on the message receiver; in other words the subscriber can
>> not just tell the messaging service to push to some arbitrary server,
>> the subscriber needs to control that specific URI space on that
>> server; it is really the subscriber's space in the end of the day.
>>
>>> So it is an admin-level decision which is enforced by the OAuth
>>>
>> filter anyway - by authenticating (by ensuring current OAuth client_id
>> matches the records and checking the signature the secret) and
>> validating that the request URI matches the one specified by the admin
>> (subscriber) at the previous step.
>>
>>> Thus it is not obvious to me why it is worth introducing another
>>>
>> authorization layer, at least given the way the push-messaging demo
>> works at the moment. And when I'm in doubt I'm really working very
>> slowly, sorry, probably not a good thing to say publicly :-)
>>
>>> Where I can see the login modules may be introduced is when we have
>>>
>> OAuth consumers registered well in advance and say the administrator
>> allocates roles to various consumers using nice UI and then we have a
>> case where some consumers may access one (resource) service method and
>> some other consumers can access some other method only. It is not the
>> case with the push-messaging demo though.
>>
>>> cheers, Sergey
>>>
>>>
>>>
>>>> Chris Bredesen wrote:
>>>>
>>>>
>>>>> Yes.
>>>>>
>>>>> Authenticator is a Catalina/Web construct that delegates to a
>>>>>
>> Realm
>>
>>>>>
>>>>>
>>>>
>>>>
>>>>> (Catalina construct) that, in JBAS is backed by LoginModules
>>>>>
>> (JAAS
>>
>>>>> constructs, JBoss implementations).
>>>>>
>>>>> JAAS LoginModules are constrained by their own API which means
>>>>>
>> they
>>
>>>>>
>>>>>
>>>> get
>>>>
>>>>
>>>>> access to only certain callbacks (username, password, etc) and
>>>>>
>> have
>>
>>>>>
>>>>>
>>>> no
>>>>
>>>>
>>>>> knowledge of the Servlet API. You can do authentication in an
>>>>> Authenticator but that's not portable to other non-Tomcat/JBW
>>>>> environments. The naming is a bit confusing IMO. It made sense
>>>>>
>> for
>>
>>>>>
>>>>>
>>>>
>>>>
>>>>> Tomcat but adds confusion in JBAS.
>>>>>
>>>>> You don't need to worry about writing an Authenticator unless you
>>>>>
>>>>>
>>>> need
>>>>
>>>>
>>>>> access to something that you don't already get from the existing
>>>>> Authenticators, such as cookies, etc.
>>>>>
>>>>> -CB
>>>>>
>>>>> On 07/14/2010 10:53 AM, Bill Burke wrote:
>>>>>
>>>>>
>>>>>> Just guessing,
>>>>>>
>>>>>> Isn't the login module responsible for the actual authentication
>>>>>>
>>>>>>
>>>> and
>>>>
>>>>
>>>>>> authorization? Tomcat authenticator is just responsible for
>>>>>>
>>>>>>
>>>> extracting
>>>>
>>>>
>>>>>> header info?
>>>>>>
>>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> You can achieve by writing a tomcat authenticator and putting
>>>>>>>>
>> it
>>
>>>>>>>>
>>>>>>>>
>>>> in
>>>>
>>>>
>>>>>>>> WEB-INF/context.xml (JBAS) or META-INF/context.xml (tomcat).
>>>>>>>>
>>>>>>>> The auth-name is a string defined in the servlet spec.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> thanks for the tip.
>>>>>>>
>>>>>>> What is the difference between writing a custom Tomcat
>>>>>>>
>>>>>>>
>>>> authenticator and a custom LoginModule, example,
>>>>
>>>>
>>>>>>>
>>>>>>>
>>>>
>> org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule
>>
>>>> ?
>>>>
>>>>
>>>>>>> My understanding is that having custom login modules :
>>>>>>> - makes it easy to stack together different modules, as
>>>>>>>
>> shown
>>
>>>>>>>
>>>>>>>
>>>> for ex at [1]
>>>>
>>>>
>>>>>>> - but requires the explicit loading of (JBoss Security)
>>>>>>>
>>>>>>>
>>>> AuthenticationManager (at least when services are POJOs)
>>>>
>>>>
>>>>>>> cheers, Sergey
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>>
>>>>
>> http://community.jboss.org/wiki/SAMLEJBIntegrationwithPicketLinkSTS
>>
>>>>
>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 07/13/2010 11:35 AM, Bill Burke wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Remy, Anil,
>>>>>>>>>
>>>>>>>>> (I'm cc'ing jboss-dev for archive purposes)
>>>>>>>>>
>>>>>>>>> Sergey , a new web services/resteasy hire, has done some
>>>>>>>>>
>> great
>>
>>>>>>>>>
>>>>>>>>>
>>>> work
>>>>
>>>>
>>>>>>>>> around OAuth lately. I'm interested in taking his stuff to
>>>>>>>>>
>> the
>>
>>>>>>>>>
>>>>>>>>>
>>>> next
>>>>
>>>>
>>>>>>>>> level and make it consumable in a way JBoss AS users are used
>>>>>>>>>
>>>>>>>>>
>>>> to
>>>>
>>>>
>>>>>>>>> configuring security.
>>>>>>>>>
>>>>>>>>> Specifically, I'm interested in defining a OAuth
>>>>>>>>> login-config/auth-method within web.xml i.e.
>>>>>>>>>
>>>>>>>>> <login-config>
>>>>>>>>> <auth-name>OAuth</auth-name>
>>>>>>>>> <realm-name>...</realm-name>
>>>>>>>>> </login-config>
>>>>>>>>>
>>>>>>>>> This would be an initial step, eventually I'd like to be able
>>>>>>>>>
>>>>>>>>>
>>>> to
>>>>
>>>>
>>>>>>>>> configure a web app to support multiple authentication
>>>>>>>>>
>>>>>>>>>
>>>> mechanisms,
>>>>
>>>>
>>>>>>>> so
>>>>>>>>
>>>>>>>>
>>>>>>>>> that one URL could support both OAuth and traditional
>>>>>>>>>
>> clients.
>>
>>>>>>>>> Is JSR 196 the way to do this? Do we support in AS6? Is
>>>>>>>>>
>> there
>>
>>>>>>>>>
>>>>>>>>>
>>>> doco
>>>>
>>>>
>>>>>>>>> someplace? (I couldn't find with a search).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Bill
More information about the jboss-development
mailing list