Posts Tagged ‘Portal Authenticaion’

Customize IIS error pages to augment WIA authentication

Wednesday, March 30th, 2011

When you configure SSO (Single Sign-On) in the WCI portal, you’re basically telling the portal to redirect to the /portal/sso/SSOLogin.aspx page, and configuring your SSO product to “protect” that page.  I could write volumes about this topic – and probably will at some point – but for this post let’s consider Windows Integrated Authentication (WIA).

The trick to configuring Windows Integrated Authentication for the portal is to enable Integrated Windows authentication on the “sso” folder like this:

This allows IIS to authenticate the user and pass the username to the portal through the portal session.  But, if the user can’t authenticate for some reason, they may see a screen like this:

While I’ll call out a portal bug any day of the week, this isn’t one of them: the portal is doing exactly what it’s supposed to, and in this case that is NOTHING.  The above error comes from IIS, and the portal never even sees the request to take action on it. [side note: in my last post, I mentioned working on a WebDav fix for Collab; it’s looking like the problems with Windows 7/Office 2010 aren’t Collab’s “fault”, but – like this issue – are the fault of the application server handling the requests.]

Now that we’ve established the issue is with IIS and not the portal, the “fix” is pretty straight-forward.  Just craft a custom HTML error page that redirects the browser back to the portal with this code:


… then, configure IIS to use that error page when the unauthorized message is generated:

This way, if IIS can’t authenticate the user, instead of presenting the error page, it’ll send a redirect to the browser to bounce back to the portal – which will know that it’s already attempted SSO and just present the user with the forms-based login.

A Closer Look at WCI Directory Services

Saturday, May 15th, 2010

By now, you’re probably aware that WebCenter comes with an LDAP Directory Service, which has been shipping since ALUI 6.5 and poked around in with Softerra’s LDAP Browser.

I’ve been working on developing a PEI to allow users to log into any auth source without having to select one on the login form, and my dev environment didn’t have access to an LDAP or Active Directory server.  Then I realized that I did, in fact have one – it’s provided by the portal itself.

So, I used the LDAP Browser to log in with my admin credentials (user name for Administrator: cn=Administrator,dc=bea,dc=com):

… and poked around the directory to get the appropriate User and Group Query Base and Filter, plus some other attributes.  I then set up an LDAP auth source in my portal with the following settings:

… and viola! After synching the users (with some errors in the logs because you’re basically creating users with identical names as users that already exist in the portal), I was able to log in using a local portal account, but via the LDAP AWS auth source:

Practical? No.  Useful if you’re trying to create a test auth source and don’t have an LDAP or ActiveDirectory server lying around?  Yup.