AS7: Web Security - JBossWebRealm

[anil.saldhana]

I want to dedicate this thread to the web layer security in AS7.

For Web applications to utilize JACC or XACML authorization, we need the web authorization checks to go through the JBoss Security authorization stack. This is not needed for majority of applications (which just rely on what is provided by spec/RealmBase authorization checks).

I think we should make the access checks to go through our authorization stack only when desired.

JBossWebRealm:-

protected boolean useAuthorizationStack = false; //Default behavior

This property needs to be used based on the domain model settings.  Additionally, the realm should be customizable based on individual web apps (via domain model).

Additionally, we just need one security valve to incorprate what the JaccContextValve, SecurityAssociationValve etc did in AS5/6 in a very minimalistic way.  Certainly JSR-196 is something to keep in mind here.

Things to note:

1. Minimize the access control checks.
2. Realm settings can be available at per web app level.
3. Ability to incorporate behavior at web app level (such as SSO) based on domain model settings. It should be possible to enable SAMLv2 SSO at the web app level using the default IDP that can be shipped with AS7.

[rmaucher]

The config files changes for AS 7 and web are:

- Server.xml is gone, all server configuration moves to the domain model

- Per webapp context.xml is gone, any useful configuration should be added to the jboss-web.xml config file (so the realm settings should go there); parsing and handling of that file is done in metadata (from jfclere repository)

+1 for minimizing access checks, per request logins, associations of security contexts, etc, whenever possible

[anil.saldhana]

The move toward jboss-web.xml instead of context.xml is a good thing.  In many ways, the difference in behavior (META-INF and WEB-INF) between tomcat and JBAS is kind of annoying wrt context.xml

Security Domains

Since security domain configuration is usually shared between EE applications (Web, EJB, WS etc),  I think it makes sense to have the sec domain config as part of the security subsystem in the domain model.  This allows sharing of the config by reference.

[anil.saldhana]

Marcus,

this is what I plan to do.

1) Security subsystem domain model settings

This needs to install the Picketbox configuration. Atleast 1 or more ApplicationPolicy instances in the server.

2) Deployment of war files

In the DeploymentWarProcessor where the web context is created.  Something like:

JBossWebRealm jbossRealm = new JBossWebRealm();

AuthenticationManager authMgr = SecurityFactory.getAuthenticationManager( securityDomain );

jbossRealm.setAuthenticationManager( authMgr );

//Similarly authorization manager too is injected into jbossrealm

webContext.setRealm( jbossRealm );

[rmaucher]

It looks very good so far

[anil.saldhana]

At this time, I am trying to figure out the classloader landscape because the JAAS framework is failing to load the login module class. Chatted with DML to figure out options.

[anil.saldhana]

==================

(10:16:26 AM) asaldhan: dmlloyd: I need a generic classloader where I can set infinite set of delegate CLs (which will be module CLs)

(10:16:57 AM) asaldhan: ===

(10:17:00 AM) asaldhan: (10:13:54 AM) anil: marcus: maybe we can have a generic classloader with two delegates

(10:17:00 AM) asaldhan: (10:14:07 AM) anil: marcus: in our integration code (web, ejb etc) we can just use that generic CL

(10:17:00 AM) asaldhan: (10:14:25 AM) anil: marcus: GenCL( Pbox, WebCL)

(10:17:00 AM) asaldhan: (10:14:34 AM) anil: marcus: GenCL( Pbox, EJBCL)

(10:17:01 AM) asaldhan: ========

(10:17:01 AM) dmlloyd: easy, use a module with a fallback local loader :)0

(10:17:33 AM) dmlloyd: though I think there's probably a better solution to whatever problem you have

(10:17:44 AM) asaldhan: dmlloyd: that is why I am asking u.

(10:18:06 AM) asaldhan: dmlloyd: I think we have the security module (pbox).  But we also need to get hold of the integration layer CL

(10:18:15 AM) asaldhan: dmlloyd: such as web, ejb etc.

(10:18:17 AM) dmlloyd: what's the use case?

(10:19:02 AM) asaldhan: dmlloyd: the use case is this way.  The web cl may have artifacts (properties files etc) needed to make security decisions.  But the security subsystem will need the pbox module loader to load things such as security login modules.

(10:19:30 AM) dmlloyd: from what context?

(10:19:46 AM) asaldhan: dmlloyd: ?

(10:19:56 AM) dmlloyd: is this happening during a servlet request?

(10:20:12 AM) asaldhan: dmlloyd: web security check

(10:20:13 AM) dmlloyd: or an EJB call?

(10:20:22 AM) asaldhan: dmlloyd: ejb security check

(10:20:34 AM) dmlloyd: ok during both of those cases, we have a TCCL of the deployment class loader right?

(10:20:39 AM) asaldhan: dmlloyd: we use the TCCl inside to load resources if possible

(10:21:15 AM) asaldhan: dmlloyd: the depl cl does not have the Pbox loader associated

(10:21:25 AM) dmlloyd: if you know where a resource is coming from, you can choose: TCCL for the deployment, the PB module CL for PB resources, other module CLs for module-specific resources

(10:21:58 AM) asaldhan: dmlloyd: when I send a check into the security subsystem,  I need all of those

(10:22:26 AM) dmlloyd: if not, then you *may* define a module which delegates to the deployment plus any additional CLs you have (we call this an "aggregator" module), but it should only be a last resort

(10:22:54 AM) dmlloyd: for example, you should never define system-wide resources by what you find in a deployment

(10:23:15 AM) asaldhan: dmlloyd: I may be looking for resources under WEB-INF/classes

(10:23:23 AM) asaldhan: dmlloyd: that is part of the servlet cl

(10:24:00 AM) asaldhan: dmlloyd: as an user, I may write a LM that looks for resources on tccl.

(10:24:10 AM) asaldhan: dmlloyd: I dont write the LM with web apps in mind

(10:26:12 AM) wolfc: dmlloyd, I've rewritten the commits https://github.com/wolfc/invocation-api/commits/wolfc

(10:26:50 AM) wolfc: I actually expected the rebase to take the last commit time of commits squashed together

(10:29:37 AM) dmlloyd: asoldano: http://github.com/dmlloyd/jboss-modules/commit/fc36308

(10:29:38 AM) jbossbot: git [jboss-modules] fc36308.. David M. Lloyd Document out the module.xml schema, fix problems in the module ID validation

(10:29:49 AM) dmlloyd:

(10:30:19 AM) dmlloyd: asaldhan: well I think we have a couple options at our disposal.  Let me know when you guys want to start coding it up and we'll walk through a first cut

(10:30:51 AM) asaldhan: dmlloyd: I am ready and willing.

(10:30:53 AM) asaldhan: dmlloyd: I do

(10:33:50 AM) kkhan left the room (quit: Quit: kkhan).

(10:34:02 AM) dmlloyd: asaldhan: ok so what we're really talking about is setting a new TCCL while LMs do their thing, right?

(10:34:22 AM) asaldhan: dmlloyd: right.

(10:34:46 AM) asaldhan: dmlloyd: and the tccl is very short in lifetime

(10:34:47 AM) dmlloyd: are we the ones instantiating the LM or does the user create and use it without our intervention?

(10:34:51 AM) asaldhan: dmlloyd: just the security check

(10:35:32 AM) asoldano: dmlloyd, thanks, reading it

(10:35:33 AM) asaldhan: dmlloyd: the path is this:    web layer ->  web sec layer --> picketbox  -> jaas  -> class.forName(LM)  ->  scan

(10:35:47 AM) dmlloyd: ok, excellent, so we have control of that code path

(10:35:54 AM) asaldhan: dmlloyd: scan maybe looking for tccl resources

(10:36:10 AM) asaldhan: dmlloyd: I dont want to do any tccl business in PBox and beyond

(10:36:17 AM) asaldhan: dmlloyd: I want it set before PBox

(10:36:33 AM) asaldhan: dmlloyd: the same happens in EJB too

(10:37:26 AM) dmlloyd: so what we could do is create an aggregator module which includes the deployment plus picketbox and whatever else you want included and use that module CL as the TCCL during JAAS activities

(10:37:56 AM) asaldhan: dmlloyd: that can work

(10:38:21 AM) asaldhan: dmlloyd: do u have aggregator module examples?

(10:38:38 AM) dmlloyd: only static module.xml ones.

(10:38:45 AM) dmlloyd: the way we have to do this is different though.

(10:39:01 AM) dmlloyd: we need a deployer phase which constructs it and attaches it to the deployment unit.

(10:39:18 AM) dmlloyd: there is only one place in code that builds a module right now...

(10:40:08 AM) asaldhan: dmlloyd: ok got that.

(10:40:24 AM) asaldhan: dmlloyd: let me discuss the other option. tell me what the -ves are

(10:40:49 AM) asaldhan: dmlloyd: I have a TwoDelegateCL that I am going to set and throwaway for just one security check.  I set whatever CL delegates I want.

(10:41:17 AM) asaldhan: dmlloyd: what can go wrong?

(10:41:26 AM) dmlloyd: sure, just have to beware of deadlocks.

(10:41:36 AM) dmlloyd: and there may be additional cost to constructing CLs, not sure

(10:42:07 AM) dmlloyd: if you run into problems, just change your CL to extend ConcurrentClassLoader instead (from jboss-modules).

(10:42:29 AM) dmlloyd: it takes care of some of the deadlock issues you can get with delegating CLs.

(10:43:31 AM) asaldhan: dmlloyd: I suggested a generic delegating CL because multiple modules (web, ejb etc) have security checks

(10:44:20 AM) dmlloyd: right, but really you only need one per deployment

(10:44:30 AM) dmlloyd: it would just delegate to the deployment + PB really

(10:44:49 AM) asaldhan: dmlloyd: does the war deployment CL follow servlet spec CLoading?

(10:44:51 AM) dmlloyd: alternatively we could simply just add PB to all deployments implicitly

(10:45:03 AM) dmlloyd: yeah, asaldhan, but that shouldn't affect your delegate impl

(10:45:19 AM) dmlloyd: all that affects is the ordering of dependencies in that particular module

(10:45:34 AM) asaldhan: dmlloyd: the reason I asked  is  I dont want user to seek  TCCL.getResource("/WEB-INF/classes/xyz")  he seeks xyz

(10:45:45 AM) dmlloyd: right

(10:46:00 AM) dmlloyd: they won't have to do that regardless

(10:46:31 AM) asaldhan: dmlloyd: cool.  regarding implicit addition of the PB module.  if we can do it just the main subsystems, that would work.  web, ejb, jca etc

(10:46:35 AM) asaldhan: dmlloyd: that need sec checks

(10:47:03 AM) dmlloyd: sure. that's pretty easy, just add a processor in Phase.DEPENDENCIES

(10:47:32 AM) asaldhan: dmlloyd: give me an example of where this is done.  any subsystem?

(10:47:35 AM) dmlloyd: add PB to Attachments.MODULE_DEPENDENCIES on the deployment unit

(10:47:41 AM) dmlloyd: for an example, see...

(10:47:59 AM) dmlloyd: org.jboss.as.managedbean.processors.ManagedBeanDependencyProcessor#deploy()

(10:48:03 AM) dmlloyd: that's a pretty clean sample.

(10:48:11 AM) dmlloyd: pretty much any of baileyje's code makes for good examples.

(10:48:16 AM) asaldhan: dmlloyd: cool

(10:48:29 AM) dmlloyd: the relevant stuff is at the end of that method

(10:48:34 AM) dmlloyd: you don't need any of the resource roots crap

(10:53:00 AM) pmuir left the room (quit: Quit: Leaving).

(10:53:08 AM) asaldhan: dmlloyd: with a deployment unit, can I know what type it is?  web, ejb etc?

(10:53:19 AM) asaldhan: dmlloyd: or do I have check the suffix or something

(10:54:32 AM) dmlloyd: yeah different deployment types have different "markers"

(10:54:44 AM) dmlloyd: what I recommend though is adding your own attachment type

(10:54:58 AM) dmlloyd: it would be something like SECURITY_DEPLOYMENT, with a type of Boolean

(10:55:00 AM) asaldhan: dmlloyd: cool.  I think baileyje's code is self-explanatory

(10:55:22 AM) dmlloyd: then in each deployer which identifies a deployment type (i.e. war, ejb, whatever) you can add that attachment too

(10:55:30 AM) dmlloyd: that'll tell your processor to add the dependency

(10:55:41 AM) asaldhan: dmlloyd: got it. an optimization would be if there are no sec stuff in the war, dont add sec deps in any way

(10:55:58 AM) dmlloyd: right, the war deployer can make that call

(10:56:11 AM) dmlloyd: also if there are new types that you did not anticipate, they can add the marker as well

(10:56:21 AM) asaldhan: dmlloyd: right.

(10:57:20 AM) asaldhan: dmlloyd: historically, we have had security deployers happening before the web, ejb deployers

(10:57:51 AM) asaldhan: dmlloyd: so the war deployers will probably remove the attachments if there is no sec needed.

(10:57:57 AM) asaldhan: dmlloyd: based on deployment metadata

(10:58:14 AM) dmlloyd: sure, it can happen in whatever order makes the most sense.

(10:58:38 AM) asaldhan: dmlloyd: got it.  Thanks for the discussion.... I am going to copy/paste the discussion into that forum thread on web sec.

==========================

[anil.saldhana]

Marcus, I have checked in the changes to my master. Sync it.  It gives basic web security based on the UsersRolesLoginModule.

[mmoyses]

You need to push the changes to your remote so I can sync.

[rmaucher]

Ahhh, the beauty of git

I had a mock realm that can be removed in the web module, assuming the UsersRolesLoginModule really does work.

[anil.saldhana]

Ok, I will remember to push it to remote. Still getting used to git.

Apart from the web.xml security constraints, I am using  WEB-INF/classes/users.properties and WEB-INF/classes/roles.properties to get the username, passwd,roles combination needed for the UR login module.

[anil.saldhana]

What is left to be fixed:

1. The Security Dependency Processor currently adds the Picketbox module dep to all deployments. We need to be selective about this.
2. The Security subsystem currently just creates a "other" application policy with the UsersRolesLoginModule.  We need to move it to a formal security domain configuration.
3. Take a look at web security utilizing a run as being passed to it.
4. Other scenarios.

[luckferrlopess]

Hi friends,

How could I extend JBossWebRealm and where to put the correct configuration in AS7? I have here implementation in jboss 6 org and all confs are in server.xml.

thanks

Luciano.

[croco]

In JBoss AS7 there was no setter for the certMapping variable in JBossWebRealm. We need to map certificate's subject CN value to principal instead of the "hardcoded" SubjectDNMapping, so I created a patch for AS7. Therefore I extended the AS7 security-domain configuration with an additional parameter <certificate-mapping code="SubjectCN"/>. So the configuartion value could be set into JBossWebRealm, I had to add 1 class (JBossCertificateMappingSecurityManager) into picketbox.

I created a JIRA issue ([SECURITY-776] JBoss AS7 certificate principal mapping - JBoss Issue Tracker) and attached a patch file. Hope this is the correct approach.