iChain Basics in a Customer Setting
Novell Cool Solutions: Feature
By Kevin Pidd
Digg This -
Posted: 8 Mar 2006
A reader recently asked the following question:
"I created a portal server (Java) that runs under Linux with Apache/Tomcat. All user authentication is done using a MySQL database that runs on the same server.
One of my portal customers who is using iChain 2.3 wants me to customize and integrate the portal with iChain (all customer web authentication is using iChain). Is there an easy way to do this?"
And here's the response from Kevin Pidd ...
iChain forwards authentication to backend web services so that it's not necessary to modify these backend web services (generally speaking). The user authenticates to iChain accelerator based on eDirectory credentials and then gets redirected to your web service.
The user credentials can be forwarded using the formfill function so they the user doesn't have to log in again. The trick is to match the user names in your database with those in eDirectory. If the usernames are identical, you are done - otherwise, you can add some scripting to iChain to match different user names or use another attribute like "customer" or "staff".
It may be overkill. If users are already being authenticated through iChain, do they need to be authenticated again through your local database? Probably not; iChain simplifies things by administering user access to resource in a central location. Most customers who have iChain also have Identity Manager, which maintains a copy of all their user identities in a central location. This is the logical place to manage access control.
Nothing is automatic. This is how this works in a common scenario.
Let's say your web application exists on an internal network, such as webapp.internal.company.com. Users can only access from the local network, not from the internet. The company wants to provide internet access to this app so they install ichain as a reverse proxy with a public interface that has an accelerator called webapp.company.com, which redirects through the private interface to webapp.internal.company.com.
If no security is applied to the accelerator, and if your webapp requires login, the login dialog will be presented to the user.
If security is applied to the accelerator, the user will be presented with an iChain login dialog when webapp.company.com is hit. The login is tested against by an iChain LDAP call to check access rules; then it is passed through to webapp.internal.company.com.
If the webapp has security, the user will see that login dialogue as well. It may be easier to dispense with this security and just apply security through the iChain LDAP database. If that is not possible, then formfill can be invoked to automatically supply the credentials backend web app so the user does not have to login again. Typically this means just passing through the username and password that was used to login to iChain, but this can be a static dialogue or credentials pulled from another location.
You should push this back to your customer as these all iChain administration issues. You can download a fully functioning iChain eval to test all this, but this is really what your customer should be doing.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com