Portlet Factory, Version 6.1.2

 

Gathering user information

WebSphere Portlet Factory allows you to use whatever custom user information you need (such as the full power of the user registry in use for each deployment scenario) rather than try to force use of a least common denominator by trying to map every possible third party user security/registration system into a common user profile. There is not much in the way of widely used standards in the area of user profile information. As a result, the WebSphere Portlet Factory core is built to allow solutions built on top of it to make best use of whatever mechanism is deemed appropriate for its particular domain.

It is expected that such solutions might provide their own mapping from multiple possible third party security systems to their own store (for example, XML mapping file or RDBMS.) of user attributes particular to the applications themselves.

For instance, the core makes use of J2EE Servlet API by default. The least common denominator is thus the Servlet API calls: getRemoteUser() and getUserPrincipal(). Both calls result in a string-based username. Solutions built on WebSphere Portlet Factory would likely allow for use of this default to return the username, but then may have their own database of user attributes keyed by such users names and configured to additional user attributes from backend systems where the user information exists. These backend systems might include LDAP, a legacy RDBMS, or a third-party security system such as WAS UserProfile APIs.

J2EE AppServers are required to give you actual username and/or J2EE Application role information, for and within protected (by security constraint) resources. You should not rely on the J2EE security APIs such as request.getRemoteUser(), request.getUserPrincipal(), request.isUserInRole() from non-protected (public) models/JSPs. Also, any WebSphere Portlet Factory code that relies on these underlying J2EE Servlet security APIs, such as webAppAccess.getUserInfo(), and/or J2EE Role based profile selection, should ONLY be used within protected (by security constraint) models.

The number, name, and type of user attributes available via each of these systems can vary. It is up to the solutions themselves to determine which types of attributes are necessary, and when and how to retrieve the attributes.

For example, to retrieve UserInfo data for use in your WebApp, use the following calls, in a Java Method or Java based LJO: 

// Get a reference to a WebApp Variable XML value that we are going to store user info in for later use in this model
IXml userInfoVar = webAppAccess.getVariables().getXmlElement("userInfoVar", "UserInfo");
// Get a reference to the configured UserInfo implementation com.bowstreet.webapp.util.UserInfo userInfo = webAppAccess.getUserInfo();
// Retrieve the user id of the logged in user String username = userInfo.getUserID();
// If there are any additional user attributes for this user, get those too
// There are no other user attributes for the default J2EE UserInfo handler
// other than username/user id, but a custom handler could supply anything it wants. java.util.Iterator i = userInfo.getKnownAttributeNames(); while (i.hasNext()) { String attrName = (String)i.next();
// Note - for typical handlers these vals are all strings
// but you could conceivably write a UserInfo handler that returned
// a more complex Java object than a string for a particular user atrr value. String attrValue = (String)userInfo.getAttribute(attrName);
IXml tmpElem = userInfoVar.addChildElement("UserAttribute"); tmpElem.addChildWithText("Name", attrName); tmpElem.addChildWithText("Value", attrValue);
}

  • UserInfo handlers

    UserInfo handlers provide a common API for retrieving user information even when external security is used instead of the default J2EE-based security.

  • UserInfo interfaces

    There are two Java interfaces related to UserInfo support that you would need to implement to provide your own custom implementation of UserInfo.

  • The UserInfo.java interface

    The UserInfo.java interface is the one you implement to provide access to additional/custom user attributes.

  • The UserInfoHandler.java interface

    UserInfoHandler.java basically has a single method implement in your UserInfoHandler.

Parent topic: Overview: security methodologies

Library | Support |