Web app Security Confusion

[louise rochford]

Our scenario is:
We have username assword stored on Active Driectory, so we're planning to use LDAP to use this for user authentication in our app.
We're going to build a DB to hold the roles & resources against username, then use this for authorization. (We can't store this info in the LDAP server - we have control over the info, but can't control storage in LDAP.)
We're not using EJBs - at least not at the moment.
Form-based authentication.
A quick'n'dirty security solution would be just to code this stuff ourselves without interacting with any of the contained services. BUT I'd like to do things 'properly'...
Looks like we should:
1) declare the protected resources in web.xml (etc) - OK, can do that...
2) add servlet filters to take care of any pre-/post- authentication processing on Logon, e.g. taking the user to a specific page, rather than the page they were trying to access when they were forced to authenticate - OK, can do that too.
Over & above this I'm really confused about what we need to do. I think (looking at some articles on the info center) that we must need to create & register a class to implement the UserRegistry, otherwise WebSphere can't possibly know to go to the DB.
Is there anything else? Do we need to write an implementation of javax.security.auth.spi.LoginModule & register it as the proxy delegate?
How about WSCallbackHandlerImpl? Do we code a subclass of this or code an implementation of javax.security.auth.callback.CallbackHandler & register it with WebSphere somehow? Is this something we can use if we ever need to authenticate a user without the container triggering it?
Kyle - is this kind of thing covered in detail in your book? In an earlier post you said don't use JAAS with WebSphere. Have I slipped into using JAAS or is the above the way you were suggesting?
If anyone knows of any specific links to RedBooks on the subject it would be very useful - I always get a bit lost digging around on the IBM website!
Many thanks,
Louise

[Rufus BugleWeed]

BUT I'd like to do things 'properly'...

I like your style.
Have you found 8.3 CustomRegistry SPI in RedBook SG24-6573-00?

[Kyle Brown]

Yes, you've slipped into JAAS. You do not need to build your own database to hold authorization information. That's already there in the product! Also, Rufus, a custom registry won't help -- they're using Active Directory for Authentication and that's already supported in the product.
Reading my book's chapter on security would probably help, as would reading the entire redbook containing the chapter Rufus mentions. It should clear things up immensely regarding how WebSphere security works.
Kyle

[louise rochford]

Aha, thanks so much. This is starting to make sense now!
(Just got to figure out how to access a double-sided printer so I can read it properly this weekend without lugging a whole tree home)
I really like the idea of using this arrangement, but there are buts...
1)I've heard that declarative secruity is great but starts to become insufficient / difficult to manage in more complex apps. Have you experience to the contrary (I'm sure I've also heard that programmatic security is OK for small apps, but a propblem on complex apps.)
2) There's a concern that we'd have to redeploy /restart the server to change the security rules. I'm kind of comfortable with this - it seems reasonable e.g. for a new user to have to wait until the server restarts before they're allowed access. Is there a way round this if the management don't think this restriction is OK?
3) It would be nice to be able to develop an app, give it to a user & have them configure which users fall into which role. If the user to role mapping is bound up in the configuration file for the app they'd have to go through either ourselves or a technical support team. I can see this actually has benefits - the users are pevented from assigning roles to features which don't make intergral sense, but it could be seen as too prohibitive. I can only think that we also develop a tool to allow them to edit the application.xml in a restricted manner. Any other ideas?
There are obviously very BIG benefits too not coding our own solution - sooo much simpler, quicker, keeps the application rules with the application, & (depending on how you look at it,) gives the appropriate people the appropriate responsibilities. I guess I just need to be sure I have all my counter-arguements lined up.
If you have any further ideas on the above they'd be much appreciated.
Cheers,
Louise

[Gary Craig]

____________________________________________
2) There's a concern that we'd have to redeploy /restart the server to change the security rules. I'm kind of comfortable with this - it seems reasonable e.g. for a new user to have to wait until the server restarts before they're allowed access. Is there a way round this if the management don't think this restriction is OK?
3) It would be nice to be able to develop an app, give it to a user & have them configure which users fall into which role. If the user to role mapping is bound up in the configuration file for the app they'd have to go through either ourselves or a technical support team. I can see this actually has benefits - the users are pevented from assigning roles to features which don't make intergral sense, but it could be seen as too prohibitive. I can only think that we also develop a tool to allow them to edit the application.xml in a restricted manner. Any other ideas?
____________________________________________________________________
The only time a server would need to be restarted is if you are changing the server's security settings. Not something you are likely to do.
You would have to restart an application if you change role mappings (or any other changes to web.xml/application.xml)
You have to configure a application J2EE role bindings a first time. Here roles are going to be associated with groups in your LDAP or special groups defined by WebSphere. Thus, by changing group membership in LDAP you will affect all future authorization checks.
I do have some concern about your indication that there are few controls over who/how updates are made to your LDAP (Active Directory). If that is the case -- coming up with a sane security implementation may be fruitless!
[ January 22, 2004: Message edited by: Gary Craig ]

[louise rochford]

LDAP is only going to be used to hold username against password. I don't expect it to have any concept of which user is in which group / role - that would be left to the application.xml file.
... so there wouldn't be a way to change the access rights outside of WebSphere.
I think the problem may be that the controls over who can update LDAP are too restrictive. We're piggy-backing on an exisitng LDAP server that's already used for lots of other stuff well outside the realm of our department. They are fine with us accessing it to check against company-wide authentication rules, but don't want to be bothered with effectively administering fine-grained control over who can access what little resource in our app.

[louise rochford]

Mmmm. I'm starting to think that we should start off using the standard WebSphere security model. It may well become too much of an overhead to maintain the user to role mapping in this way, at which time we can then switch to using some bought-in component (like Tivoli Access Manager or SiteMinder) to handle this for us.
Does this sound like a reasonable approach?
Would the re-configuration to an external tool be simple, or is it considerably easier to get the Access control component linked up from the start?
Any Access Control components out there that are significantly easier to use / intergrate best with WebSphere / most popular?
Thanks,
Louise

[Kyle Brown]

Originally posted by louise rochford:
LDAP is only going to be used to hold username against password. I don't expect it to have any concept of which user is in which group / role - that would be left to the application.xml file.
... so there wouldn't be a way to change the access rights outside of WebSphere.
I think the problem may be that the controls over who can update LDAP are too restrictive. We're piggy-backing on an exisitng LDAP server that's already used for lots of other stuff well outside the realm of our department. They are fine with us accessing it to check against company-wide authentication rules, but don't want to be bothered with effectively administering fine-grained control over who can access what little resource in our app.

Actually, LDAP does have a group membership concept. We recommend that you use LDAP groups to map to J2EE roles, and support that mapping in WebSphere. If the group mapping doesn't work for you, then I'd probably recommend you use another (different) LDAP server that replicates at least part of its information from the original LDAP server. Failing that, you could build a custom registry...
Kyle
[ January 23, 2004: Message edited by: Kyle Brown ]

[louise rochford]

OK, our LDAP server will hold groups & users so the authentication part is on the way to being sorted out.
However, it's become clear that we need to hold the authorization data on a database. Holding the authorization data within WebSphere isn't sufficient. This is partly so that it can be accessed / managed from outside of our app. & partly so that we have the option to specify very fine grained access (eg display of links on a page) if / when we need to.
Is there any way to configure the authorization to run against the database without throwing away all the other benefits of declarative & programmatic security?

[Kyle Brown]

No, it can't be done. You can't substitute WebSphere's role-based security with something else, and there's no way to delegate that to something else.
And I do cover how to do fine-grained security in your view (together with J2EE role-based security) in my book.
Kyle