[undertow-dev] Authentication Mechanism Configuration

Mon Nov 25 15:26:41 EST 2013

I think the real issue is making extensions 'play nicely' with each other. Basically something like:

<auth-method>oauth?config=1,SPNEGO:config=2</auth-method>

Basically there is no way for a single extension to deal with that, as it needs to know about both methods. 

You could do something like:

<auth-method>com.acme.OauthProvider?config=1,com.acme.SPNEGOProvider:config=2</auth-method>

But listing the implementation class names is just not as nice. One option would be to allow ServletExtensions to explicitly register an AuthenticationProviderFactory under a given name, and then this name will be used to construct it from the <auth-method> (although then there is the possibility that two extensions will pick the same name, so probably pick use a full qualified name for the auth method, like org.keycloak.oauth).

> 
> Maybe look at it more generically rather than as something specific to
> security?  Make the focus around ServletExtension. (is there an Undertow
> only extension?).  I say this because, at least for Keycloak, I needed
> to not only add AuthMechs, but also handlers as I needed something to
> run before and after auth.  I also think that yuor #4, "Overriding the
> default definition in an app" is also applicable to non-security
> functionality.  So I would vote for a way to attach a ServletExtension
> to a specific deployment declaratively without using META-INF/services
> 
> For the case of:
> 
> <auth-method>org.some.class?config=1;config=2</auth-method>
> 
> You could just provide an implementation of ServletExtension that parses
> the string.  Maybe even make this string a URL
> 
> i.e.
> 
> <auth-method>extension://class.name/path?config=1&config=2</auth-method>
> 
> Maybe even take this further up the chain and provide a way within
> Wildfly to attach a Wildfly extension per deployment.  Works as long as
> Undertow DeploymentInfo is available as an attachment in the Wildfly
> deploy flow.  This would be important for applying security (and other
> features) to other environments beyond Undertow.

This is pretty similar to what I suggest above, except that Undertow itself will parse the string, and we don't use the actual class names for the authenticators. It probably does not make that much difference either way.

Stuart

> 
> 
> 
> On 11/25/2013 1:10 PM, Darran Lofthouse wrote:
> > I think these are the main problem areas we could choose to solve.
> >
> > 1 - Definition of new mechanisms.
> > 2 - Chaining of mechanisms.
> > 3 - Custom mechanism configuration.
> > 4 - Overriding default definition in an app.
> >
> > For #1 the ServletExtension makes that quite easy, if you want to add a
> > new mechanism to WildFly you can add it as a module or within the
> > deployment - provided it is found by a ServiceLoader it can set the
> > mechanism and as the extension was found class loading should be
> > simplified.
> >
> > #2 is also already in there, I see the mechanisms now support being a
> > comma separated list.
> >
> > The issue there however is that I don't think  #1 and #2 are working
> > together cleanly, i.e. we may have an ordered list of methods and
> > ServletExtension implementations assuming only one mechanism is
> > specified - or even if the ServletExtension does take it as a comma
> > separated list no way for the two to work together to get the mechanisms
> > in the desired order.
> >
> > For #3 we could concentrate on the areas involving the standard
> > mechanisms, we still need config for SPNEGO and we need a few more
> > options for Digest - there is a chance some of this config could become
> > specific to the web app but we could leave that until it becomes a problem.
> >
> > For #4 I have seen demand for taking a web app with existing
> > configuration and overriding the security settings without modifying the
> > app - this would allow the same app to be taken through development
> > through QA, staging and into production with just the servers
> > configuration differing.
> >
> > But then maybe what we have is sufficient, if the PicketLink subsystem
> > is going to be setting mechanisms maybe that is the place a chained
> > configuration should be defined.  I think this is going to be a key
> > question - long term as we place more emphasis on PicketLink IDM where
> > is the responsibility going to be to set a chain of authentication
> > mechanisms?
> >
> > Regards,
> > Darran Lofthouse.
> >
> >
> >
> > On 25/11/13 15:48, Stuart Douglas wrote:
> >> If we allowed users to set ServletContext attributes at the subsystem
> >> level, you could also support the subsystem wide case via
> >> ServletExtension.
> >>
> >> Basically instead of looking at the auth mechanism an extension can look
> >> at the servlet context attributes and decide to activate or not.
> >>
> >> Not sure if we also need a 'cleaner' way to do this.
> >>
> >> Stuart
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> >>> To: undertow-dev at lists.jboss.org
> >>> Sent: Monday, 25 November, 2013 4:37:06 PM
> >>> Subject: Re: [undertow-dev] Authentication Mechanism Configuration
> >>>
> >>>   From my side, the deployment level approach will suffice.
> >>>
> >>> Since a deployment goes through the PicketLink WildFly Subsystem, we can
> >>> always
> >>> use the Undertow API to replace the default authentication mechanism
> >>> with what we need, in the PL subsystem.
> >>>
> >>> I am unsure if we have WF users who really want to bulk change
> >>> authentication mechanisms in a few web archives
> >>> at the subsystem level.
> >>>
> >>> On 11/25/2013 09:25 AM, Darran Lofthouse wrote:
> >>>> I am in favour of both deployment specific approaches and subsystem
> >>>> specific approaches - as you say we have two different audiences to make
> >>>> use of this.
> >>>>
> >>>> Looking at your specific mechanism what level of configuration would you
> >>>> require?
> >>>>
> >>>> If you have any complex requirement for the deployment specified
> >>>> configuration could you follow a similar approach to Bill and use a
> >>>> ServletExtension?
> >>>>
> >>>> Regards,
> >>>> Darran Lofthouse.
> >>>>
> >>>>
> >>>> On 25/11/13 15:19, Anil Saldhana wrote:
> >>>>> On 11/25/2013 09:15 AM, Darran Lofthouse wrote:
> >>>>>> On 25/11/13 15:11, Anil Saldhana wrote:
> >>>>>>>> In my usecase, I want to install my custom authentication mechanism
> >>>>>>>> irrespective of what is defined in web.xml
> >>>>>> That is what I want to to be able to achieve on the subsystem side of
> >>>>>> the configuration.
> >>>>>>
> >>>>>> I have lost count of the number of times I have seen users say, "I
> >>>>>> want
> >>>>>> to take a single jar and deploy it to a development machine and a
> >>>>>> production machine and have different security settings applied on
> >>>>>> each"
> >>>>>> - with the subsystem side of the configuration this is something I
> >>>>>> want
> >>>>>> to be able to achieve.
> >>>>>>
> >>>>>>>> This is done in JBossWeb by having an authenticator valve via
> >>>>>>>> context.xml in the deployment.
> >>>>>> Do you see the separate descriptor as a requirement or is that just
> >>>>>> how
> >>>>>> we have done this before?
> >>>>>>
> >>>>> Two scenarios:
> >>>>> a) You can just deploy a web archive with the descriptor and get the
> >>>>> functionality.
> >>>>> b) Configure at the subsystem level to apply the customization to
> >>>>> selected set of web archives.
> >>>>>
> >>>>> The first scenario is useful for developers who are trying out WF. The
> >>>>> second scenario is for devops.
> >>>>>
> >>>>> It may be better to support both.  Primarily we can recommend subsystem
> >>>>> level configuration while
> >>>>> supporting deployment level configuration also if desired.
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 