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(a)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