Thursday Jan 17, 2008


Back to normal programming. No more infocard stuff here. With a typical Access Manager deployment atop a webserver or appserver, there are many instances where apart from the Access Manager services deployed, one may deploy other applications on the same server instance and may need to "protect" them. The right way of going about it is to deploy a policy agent on the same server instance. I noticed that in some cases folks choose not to deploy an agent but "embed" code in every page of their webapp to check for the validity of the SSOToken issues by AM and enable access to thise pages that they need "protected". Well, if all one needs is to protect a few URI's that reside on the same server instance as AM, one could also use a Servlet Filter to do the same without having to embed code in every page of their application to check for it. This is a simple SSO only method and not a replacement for a policy agent. Here's what one needs to do to enable this. Declare the [filter] element in your web application deployment descriptor. For Sun's Webserver it would be the default-web.xml file. Map the filter to a servlet by defining a <filter-mapping> element in the deployment descriptor. This element maps a filter name to a servlet by name or by URL pattern. Add the URL's you would like to "protect" to the url-pattern tag element.
Now compile the attached code, build a jar file and add it to your servers classpath.
for some reason I just cannot post code on this blog. No matter what I try, the code gets converted over to HTML. I did follow Pat's advise, but that didnt help. So I'm uploading the file and providing you a link to download it instead of posting code as inline text
Restart your webserver.
  • Try accessing the "protected" URL without authentication.
  • Try accessing the "protected" URL with authentication.
You'd see the difference... NOTE: This is NOT a replacement for a Policy Agent. This is just an FYI/example of how one could achieve SSO only using a Filter.

Access Manager 7 - PREVIEW

Yes !!! Access Manager 7 is coming out. pretty soon... Here's a Sneak Preview...(I Shall Provide More Screenshots AFTER the binaries are publicly released)Whats New ?
  1. New Access Manager Console
    The Access Manager Console has been redesigned for this release. If Access Manager is deployed with any of the following products, however, you must install Access Manager in Legacy Mode and use the Access Manager 6 2005Q1 Console:
    • Sun Java System Portal Server
    • Sun Java System Communications Services servers: Messaging Server, Calendar Server, Instant Messaging, or Delegated Administrator

    For more information, see Compatibility Issues.

  2. Identity Repository
    An Access Manager identity repository contains information pertinent to identities such as users, groups, and roles. You can create and maintain an identity repository using either Access Manager or another provisioning product such as Sun Java System Identity Manager. An identity repository can reside in either Sun Java System Directory Server or any other LDAP version 3 (LDAP v3) compliant directory server. Access Manager can have read/write access or read-only access to an identity repository.
  3. Access Manager Information Tree
    The Access Manager information tree contains information pertinent to system access. Each Access Manager instance creates and maintains a separate information tree in Sun Java System Directory Server. An Access Manager information tree can have any name (suffix). The Access Manager information tree includes realms (and sub-realms, if needed). A realm (or sub-realm) contains configuration information that defines a set of users and/or groups, how users authenticate, which resources users can access, and the information that is available to applications after users are given access to resources. (A realm or sub-realm can also be empty.) For more information, see Access Manager Installation Modes.
  4. Session Property Change Notification
    The session property change notification feature enables Access Manager to send a notification to the specific listeners when a change occurs on a specific session property . This feature takes effect when the “Enable Property Change Notifications” attribute is enabled in the Access Manager administrator Console. For example, in a single sign-on (SSO) environment, one Access Manager session can be shared by multiple applications. When a change occurs on a specific session property defined in the “Notification Properties” list, Access Manager sends a notification to all registered listeners.
  5. Session Quota Constraints
    The session quota constraints feature allows the Access Manager administrator (amadmin) to set the “Active User Sessions” attribute to limit the maximum number of concurrent sessions allowed for a user. The administrator can set a session quota constraint at the global level for all users or for an entity such as an organization, realm, role, or user that apply only to one or more specific users. By default, session quota constraints are disabled (OFF), but the administrator can enable them by setting the “Enable Quota Constraints” attribute in the Access Manager administrator Console. The administrator can also configure the behavior if a user exhausts the session constraint quota by setting the “Resulting Behavior If Session Quota Exhausted” attribute:
    • DENY_ACCESS. Access Manager rejects the login request for a new session.
    • DESTROY_OLD_SESSION. Access Manager destroys the next expiring session.
    The “Exempt Top-Level Admins From Constraint Checking” attribute specifies whether session constraint quotas apply to the administrators who have the “Top-level Admin Role”.
  6. Distributed Authentication
    The distributed authentication service allows user identity and credential collection interaction for the demilitarized zone (DMZ). During authentication to Access Manager, the user must provide user identification and credentials. During this process, the Access Manager service URLs are exposed to the user. You can avoid this exposure by using a proxy server; however, a proxy server is not an acceptable solution for some deployments. Most of the secure deployments do not allow Agents (from the DMZ layer) redirecting the request to the Access Manager server (in secure zone, behind the firewall) directly and hence this is the primary requirement for the Distributed Authentication service. This feature is delivered and deployed as J2EE Web application on any servlet compliant Web container. The Authentication Service can have a remote authentication presentation and extraction framework (that is, distributed authentication UI) that can be deployed as J2EE Web application in the DMZ layer (on a machine not running Access Manager) and which in turn, can communicate with back-end servers for the actual authentication. The Distributed Authentication service communicates to the Authentication server (remotely) for actual authentication via remote API.
  7. Multiple Authentication Module Instances Support
    All authentication modules (out of box) are extended to support the sub-schema with Console UI support. Multiple authentication module instances can be created for each module type (module class loaded). For example, for instances with names of ldap1 and ldap2 for an LDAP module type, each instance can point to a different LDAP directory server. Module instances with the same names as their types are supported for backward compatibility. Invocation is server_deploy_uri/UI/Login?module=module-instance-name.
  8. Authentication “Named Configuration” or “Chaining” Name Space
    A separate name space is created under an Org/Realm, which is a chain of authentication module instances. The same chain can be reused and assigned to an Org/Realm, Role, or User. The Authentication Service instance equals the Authentication Chain. Invocation is server_deploy_uri/UI/Login?service=authentication-chain-name.
  9. Policy Module Enhancements
    Personalization Attributes
    In addition to Rules, Subjects, and Conditions, policies can now have personalization attributes (IDResponseProvider). The policy decision sent to the client from the policy evaluation now includes policy-based response personalization attributes in the applicable policies. Two types of personalization attributes are supported:
    • Static attributes. You define the attribute name and value in the policy.
    • Dynamic attributes. You list the attribute names in the policies, and values are fetched from the Identity Repository data stores at policy evaluation time.
    Policy Enforcement Points (agents) typically forward these attribute values as HTTP Header or Cookies or Request Attributes to the protected application.

    Access Manager 7 2005Q4 does not support custom implementations of the Response Provider interface by customers.

    Session Property Condition
    The session policy condition implementation (SessionPropertyCondition) decides whether a policy is applicable to the request based on values of properties set in a user's Access Manager session. At policy evaluation time, the condition returns “true” only if the user's Access Manager session has every property value defined in the condition. For properties defined with multiple values in the condition, it is sufficient if the user session has at least one value listed for the property in the condition.

    Policy Subject
    The policy subject implementation (AMIdentitySubject) allows you to use entries from the configured Identity Repository as policy subject values.

    Policy Export
    You can export policies in XML format using the amadmin command. The new GetPolices and RealmGetPolicies elements in the amAdmin.dtd file support this feature.

    Policy Status
    A policy now has a status attribute, which can be set to active or inactive. Inactive policies are ignored during policy evaluation.

  10. Site Configuration
    The site configuration feature provides simple and centralized configuration management for Access Manager deployments that have multiple Access Manager instances behind a load balancer. Access Manager can be configured in session failover mode, if required for the deployment. To configure the site configuration, use the Access Manager Administrator Console, under Configuration, System Properties, and then Platform.
  11. Bulk Federation
    Access Manager 7 2005Q4 provides bulk federation of user accounts to applications that are outsourced to business partners. Previously, federating accounts between a Service Provider (SP) and an Identity Provider (IDP) required each user to access both the SP and IDP sites, create accounts if not already there, and federate the two accounts through a Web link. This process was time consuming. It was not always suitable for a deployment with existing accounts or for a site that acted as an identity provider itself or use one of its partners as an authenticating provider.
  12. Logging Enhancements
    Access Manager 7 2005Q4 includes several new logging enhancements:
    • New fields (or columns): The MessageID field contains the message identifier for the logged event. The ContextID field contains the context identifier, which is analogous to a session identifier and applies to all events for a particular user's login session. For a user's specific login session, ContextID will be the same in all log files for logged events.
    • Logging API. The API includes additions for reading log records, including from a database (DB), when logging to DB is configured. Refer to in the /opt/SUNWam/samples/logging directory, which shows the retrieval of log records from a flat file or DB table repository.
For More information See The Docs

for everything on Identity, JCAPS, SOA, WebServices, Security, Single Signon, Federation, Provisioning, Virtualization, Optimization, Debugging, Workflows, Compliance, MySQL and more... WAY MORE....

[this is a group blog]


« February 2017