FAM Architecture Overview

{toc}

h4. 1.0 Audience

This document is designed to provide a overview of Federated Access Manager (FAM) architecture. Finer details of each component are covered in individual documents. An effort has been made to structure the text to cater to the needs of both those who want just the big picture and those who want to understand the internals. Please refer to OpenSSO docs \[[#1]\] for a overview of the technical conceptual model and use cases that form the basis of a web access management product. This doc should not be used for product information the official product documentation \[[#2]\] is more appropriate for this, especially the 'Technical Overview document, which provides a excellent introduction to customer visible aspects of FAM.

h4. 2.0 30 Second (Elevator Pitch) Architecture

FAM provides complete and flexible access management and federation management capabilities, in the form of a simple lightweight Java EE application \[[#3]\] thereby scaling horizontally and vertically as enterprise security needs change over time.

The following services are provided :
# Authentication
# Authorization (Policy)
# Session (SSO)
# Auditing/Logging
# Identity Repository access
# Federation
# Web Services Security

!overallarch.JPG! Figure 1

The server component of services 1 thru 5 is a simple Servlet receiving requests as XML and returning responses in XML. [FAM web.xml|^web.xml] shows the Servlet mappings. Services (6) and (7) are based on federated identity and web services standards (OASIS SAML \[[#3]\], Liberty Alliance \[[#3]\], WS-Security \[[#3]\], WS-Trust \[[#3]\], WS-Federation \[[#3]\]).

A browser based console and command line interfaces are supplied with the product to configure and manage FAM. Local bootstrapping and per server configuration is provided via the AMConfig.properties file.

Policy Agents (PAs) are provided as add-on components one for each container type that ease the protection of web based network resources (enterprise applications and services). PAs consume the public APIs mentioned above and take care of the integration with the specific container such that its presence is largely transparent to the contained protected resources. Please refer to \[[#8]\] for a complete list of currently supported PAs.

h4. 3.0 Design Goals


h5. 3.1 Cater to Both Web and Non-Web-based Resources.

There is often a misconception that FAM caters to Web Access Management (WAM) only. While it is true that most FAM deployments address the web single sign-on problem, the core design caters to both web and non-web applications.

h5. 3.2 Security

Runtime security that enables resources to be protected as configured and FAM services accessible to authorized entities only.
Administration security to ensure only authorized updates to configuration,
Deployment security that implements best practices for FAM installation on misc operating systems, containers, etc.
All actions : administration related and runtime access related are logged.

h5. 3.3 Ease of Deployment and Administration

Minimum steps to get FAM up and running.

h5. 3.4 Performance, Scalability and Availability

No single point of failure, ability to scale horizontally and vertically

h5. 3.5 Distributed Architecture

Server and client components can be deployed across the enterprise or across domain boundaries.
As a result all APIs need to be remoteable. Exposure via Web Services is a key goal here to enable exposing Identity as a service in a SOA environment.

h5. 3.6 Flexibility & Extensibility

Every service needs to expose a service provider interface (SPI) that allows the framework to be expanded to specific deployment needs.

h5. 3.7 Open Standards

Adopt standards as far as possible.

h5. 3.8 Internationalization (i18n)

All customer facing messages i18n'ed includes all APIs, CLIs and UI.

h4. 4.0 Common Service Infrastructure

This section describes the common design patters followed by all services.

h5. 4.1 Communication Protocol

Clients (e.g. agents, applications using  FAM APIs) request FAM services (for example, in response to a user accessing a protected resource). FAM services issue notifications to registered clients to communicate events (e.g. session expiry, policy decision change, user profile change, configuration change etc) A mix of proprietary XML over https (Platform Low Level, or PLL) and SOAP is used for communication between clients (eg agents, SDK) and server. Following figure shows the basic communication between FAM components.

!pll.JPG! Figure 2'
\[[#5]\] provides the common PLL DTD and related service specific DTDs. Figure 3 shows the class diagram representing the key elements in these DTDs.
Clients send Requests to services; the PLLServlet on the FAM server receives these requests and dispatches them to the appropriate service handler. Service handlers process the request and format a Response that is then returned to the client. Please refer to the DTDs for specific operations supported by each service. Low \-level design documents for each service explain each operation in detail.

!pllxml.JPG! Figure 3
A special configuration attribute : "com.iplanet.services.comm.server.pllrequest.maxContentLength" allows deployments to limit the size of the the network data payload (default value is 16K) as a simple mechanism to prevent network attacks on exposed interfaces via PLL.

h5. 4.2 Naming Service

The Naming Service is a special service that provides bootstrap information on the location of FAM servers to the clients. The Naming service contains information on the location of each FAM service. Example naming service URL :
[http://famserver.sun.com/fam/namingservice]

A request to the naming service returns the URLs of individual FAM services :
Eg:
[http://famserver.sun.com/fam/authservice]
[http://famserver.sun.com/fam/sessionservice]
[http://famserver.sun.com/fam/policyservice]
[http://famserver.sun.com/fam/loggingservice]

h5. 4.3 Client API

Most of the communication protocol and bootstrapping described earlier is encapsulated in APIs Java and C one for each service exposed. The APIs internally implement a cache that is kept in sync with the server in two ways :
a) Polling mode/lazy cache - cache entries go stale and are retrieved from the server reactively.
b) Notifications mode the API explicitly registers for events and uses the events to sync the cache.

All Client API access must carry proof of authentication before the request is served - please see description of SSOTOken and Authentication subsection on how this works. Access to a service via APIs is also resricted on the context and the user's roles and privileges.

h5. 4.4 SPI

Service Provider Interfaces make each FAM service extensible. SPIs supplied by each service are listed in respective sections in this document. The SPIs are Java interfaces that are implemented by concrete classes and registered with the FAM via configuration. Several plugin implementations are preregistered out-of-the-box. Specific deployments may choose to extend them or to replace them entirely.

h5. 4.5 Configuration

Configuration data needed for each FAM service is specified in two ways :
a) AMConfig.properties a per-server flat file co-located on the server instance.
b) A Configuration repository (eg Flat File or LDAP server) shared across all FAM servers forming the same cluster.
The core purpose of AMConfig.properties is to provide bootstrap information and to store per server configuration, and that of the Configuration repository to store the rest of configuration required at runtime. However, in practice this rule is not strictly followed i.e. some small percentage of the shared runtime data is stored in AMConfig.properties for misc reasons (hotpatches, historical reasons, etc). A future release will address this issue.

h5. 4.6 Multiple Servers and Sites

As noted earlier, horizontal scalability is achieved by multiple FAM servers acting as a cluster. Typically a load balancer is deployed to distribute load appropriately to the underlying servers. Servers may be distributed across geographic locations. To enable physical servers to be hidden behind load balancers and to allow geolocality for clients, FAM supports the notion of a site which is essentially a group of co-located FAM servers that are served via the same URL exposed by the fronting load balancer.

{anchor:SSOTokensTheGlue}

h5. 4.7 SSOTokens : The Glue

Users authenticate using credentials (eg userid/password, Radius, certificate, etc). Similarly misc distributed FAM entities (clients & agents) also use their server credentials to authenticate to FAM. The result of a successful authentication results in the creation of a Session for the user/entity and a opaque handle (essentially a secure random number) known as an SSOToken. SSOToken becomes the basis for exchanging proof of authentication between FAM entities. For example, a web based user authentication to a FAM server results in creation of an SSOToken stored as a cookie in the user's browser. As the user visits different protected resources from this browser, the SSOToken is propagated to these resources they (via a embedded client API or agent) can then dereference the SSOToken by sending a validate request to a FAM server that returns either an error or a copy of the session containing the prior authentication information such as auth level, auth module, instant of authn, idle time, etc (details in session id. Access to some FAM services, such as Policy and logging require presentation of both the SSOToken of the application as well as SSOToken of the user to allow only designated applications to access these services. Sessions (and hence SSOTokens) are invalidated when a user logs out or the session expires or a user in an administrative role invalidates a user's session.

h5. 4.8 Security : Credentials and Delegation

Transport level communication between FAM entities is secured with SSL.

User passwords (both administrator and normal user )  are subject to certain rules (such as length, complexity, history, etc). FAM relies on the underlying authentication framework to impose these rules. For example, when Sun Directory server is configured as the authentication mechanism (default) it is expected administrators setup the appropriate password policy  as described in the product documentation (Appendix B). Errors from the underlying framework  password policies are caught by FAM by providing the error message to the enduser and logging the event.

Some passwords and credentials need to be stored on local FAM server systems (AMConfig.properties and serverconfig.xml) :
a) Configuration store location and userid+password.
b) Digital signing keystore location and credentials to access it.
c) SSOToken encryption key.

FAM relies on Operating System's filesystem security to protect access to these files.

Some passwords and credentials need to be stored on the configuration store - for example, Identity Repository location and credentials are required to be able to search for users. Read access is sufficient unless FAM is expected to be an interface to writing to user profile data and/or needs to provide 'User Management' features such as management of roles and groups.

All passwords stored locally in files and in configuration directory are encrypted with a secret key using PBEWithMD5AndDES algorithm.

A realm is the administrative unit of administering FAM. With the exception of initial bootstrap information that is configured at install-time the rest of FAM configuration is accomplished via one the following mechanisms :
a) the Admin Console GUI based interface to all FAM components.
b) Command Line Interfaces : amadm and fmadm.
c) Administration APIs in effect both (a) and (b) are built using these APIs.

Administrators are assigned roles that allow users assigned these roles to perform all or specific tasks in a realm. The realms form a hierarchy starting with the root realm created out of the box. Specific component configuration can be attached to a realm, please refer to specific component documentation for details on how they leverage realm based delegation.
Figure 4 depicts an example deployment that uses a hierarchy of realms to distribute administration responsibilities.

!MIT.JPG! Figure 4
Table 1 shows the default privileges and roles they are assigned to.
| | __Privilege__ | __Roles__ |
| 0 | "None" - default | No access to any data - default for all regular users |
| 1 | Read only access to data stores | Custom roles can be added and assigned this provilege either for all realms or particular realms. |
| 2 | Read and write access only for policy properties | Policy Administrator applies to policies in all realms. Realm Policy Administrator applies to policies in a particular realm. |
| 3 | Read and write access to all realm and policy properties | Realm Administrator access to all realms. Sub-realm Administrator access to a particular realm. |
| 4 | Read only access to all properties and services | Custom roles can be added and assigned this privilege either for all realms or particular realms. |
| 5 | Administer Audit logs : turn on/off, change level, view logs | Log Administrator manages logs for the entire installation.  \\
Custom roles can be added and assigned this privilege either for all realms or particular realms. |

h5. 4.9 Repositories

FAM services needs to interact with miscellaneous backend stores. A commom LDAP connection pooling facility allows efficient use of network resources. In a extreme deployment the following 4 distinct reposiotries can be configured :
# User repository(ies) - consumed by IDRepo service to provide profile information
# Configuration repository - consumed by the common configuration service to store service specific data
# Authentication store(s) - consumed by Authentication service as the authoritaive autehntication source
# Policy Subjects store(s) - consumed by Policy service to evaluate policy subjects.

In the simplest scenario a single LDAP repository is sufficient to cater to all the 4 kinds, however, the typical case tends to be configuration store to be separate from the rest of the stores that use the same corporate directory.

h5. 4.10 Logging

A common Logging service is invoked by all components - both residing on the server and those on the client. This allows the actual mechanism of logging (such as formatting (eg ELF/XML) and destination (eg flatfile/RDBMS))to be seperated from contemts of the logs, which are specific to each component. The common log attributes for all kids of logs are :
* Module Name - component/service he log information pertains  to
* Message ID - each log message type has a unique message id. Message ids allows machine reading/filtering of log records.
* Timestamp
* ContextId - per session unique identifier that allows correlation of log records per user session.
* Logged By (identity of a authorized user who created the log entry - typically client component)
* Userid (identity of the user who performed the action)
* IP Address (of the user agent used to access the component)
* DNS Domain Name (if available) of useragent host
* Authentication type (how the user authenticated)
* Data - field used to store transaction specific data.

Secure remote logging facilities (API and over the wire protocol) results in centralized logging. Administrators can control log levels, authorize the entities that are allowed to create log entries and configure secure logging. Secure logging follows a standard log digital signing mechanism to ensure logs are tamper proof. Logging API and SPI are based on jsr045 (JDK Logging) - it is enhanced for use in a secure environment. Please refer to low level design of the logging service for details.

h5. 4.11 Monitoring

FAM monitoring is based on JES Monitoring framework documented in \[[#7]\]. The basis of monitoring are Java Management Extensions and Common Management Model, both system management standards. Each FAM components is instrumented to provide fault and statistical data that is reported back to a centralized management console. Following are examples of data reported :
* Number of attempted, successful, and failed authentications
* Number of active sessions, statistics from session failover DB
* Session failover database statistics
* Policy caching statistics
* Policy evaluation transaction times
* Number of assertions for a given provider in a SAML/Federation deployment

h5. 4.12 Putting it together

The following figure shows a physical deployment of FAM server and how things get bootstrapped at runtime. Start with the FAM server installed in a Java EE container on the top left corner. Each arrow represents a pointer to the physical location of a component via a identified configuration parameter.

!physdeploysmall.JPG! Physical_Deployment_and_config_bootstrapping}

At startup the FAM server (deployed as FAM.war in a Java EE application server) reads its bootstrap information to find the AMConfig.properties file on the local host. AMConfig.properties in turn contains the direcroty on the local server containing the serverconfig.xml fie - this file contains data to access the configuration store (default, a LDAP server info : host, port and appropriate credentials to read and write into the store). Once the server is able to access the configuration store - it then initializes all the services - that in turn may access different data stores. Please refer to Appendix A for a summary of configuration read by each service. Protection of the deployed WAR file and misc files on the local server are all protected using OS facilities - a typical deployment creates a special user (eg amserver or root in the example above) and access is granted to privileged users only. The WAR itself may execute as this special user or may be assigned read only privileges to the config files. Debug and log files created on local server need appripriate write permission assigned to the WAR execution, and again special care needs to be taken so that non-privileged users do not have access to these files.
The following figure provides a overview of each FAM component interacts with each other in a typical SSO scenario.

!overallinteraction.JPG!

h4. 5.0 Identity Repository Access Service

The Identity Repository (IDRepo) service allows FAM to integrate a existing user repository, such as the corporate LDAP server. It provides an abstraction to access user profiles as well as group & role assignments consumed by client and other FAM services. This abstraction is capable of spanning multiple repositories even of different types. The current implementation supports any LDAPv3 compliant repository (certified for Sun Directory Server and Active Directory).
The IDRepo SPI can be used to build new adapters for repositories not currently supported.
!datastores.JPG! Figure 5

h4. 6.0 Authentication Service

The Authentication service is based on Java Authentication and Authorization Service (JAAS). Several authentication modules are supplied out of the box, examples : LDAP, Radius, SecureID, Windows Desktop, Certificate, Active Directory. New authentication modules can be added using a JAAS based SPI.
Figure 6 shows all the authentication subcomponents and how they work with core infrastructure pieces described earlier and other components.
Following auth subcomponents are identified :

!autharch.JPG! width='400' height='400' Figure 6

JSP Pages represent the UI pages that are shown to users to authenticate. These JSPs are completely customizable. The design follows the standard MVC pattern, the model supplied by the authentication client API.
Authentication API : Remoteable interfaces. Notice the AuthenticationRequest in Figure 3 maps to the the AuthenticationRequest handler in Figure 6 that handles the XML sent over PLL.

Distributed Authentication (DA) : DA is in effect an extension of FAM that allows the the UI portion of authentication to be deployed separately from the server, typically in extranet situation where it is more desirable to deploy a proxy like DA in the DMZ instead of the entire FAM server. DA uses the authentication client APIs to pass gathered credentials to the server for verification.

Authentication Middle Tier : This forms the core of authentication service executing the common processing across authentication modules. It is driven by JAAS. A key responsibilities of this layer include identification of appropriate plan to authenticate the user (identify auth module, load appropriate JSP pages) and to to create the appropriate session for the authenticated user.

Authentication SPI : The SPI is based on JAAS authentication module with some enhancements.

Authentication Modules : The actual modules configured in the system.

The concept of SSOToken is described in an [earlier section|#SSOTokensTheGlue]. Figure 7 shows Session subcomponents and their interaction. A session also serves as a efficient inter-process communication mechanism to communicate simple attributes related to the specific authenticated user.
!sessionarch.JPG! Figure 7 width='400'
Following attributes are populated by default :
\*Principal
\*Universal identifier
\*Time user authenticated
\*Authentication modules list (list of auth modules the user has autehnticated to)
\*Authentication level
\*Last accessed Time (idle timeout processing)
\*Max Time (hard limit at which the session is destroyed).

Server side code can add new attributes to be shared with clients. Clients can also add custom attributes as long as those attributes are configured on the server end.

Session Persistence architecture is illustrated below :
!amsfo2.gif! Figure 8 width='400'
It uses the efficient messaging capabilities of a Message Queue to push session information to a persistent store based on Berkeley DB. Two key features are enabled with this :
a) Session Failover : allows an alternative FAM server to pick up a given user session when the server owning the original session fails.
b) Session Constraints : allows deployments to specify constrains on sessions, such as 1 session per user.

h4. 8.0 Policy Service

The Policy Service provides the authorization service of FAM. It is a rules based engine. A Policy comprises :
Service name schema for the policy type that describes the syntax of policy (amPolicy.xml)
* Rule : Resource, Action and Value.
* Subject(s)
* Condition(s

Figure 9 shows how Policy service is built. Note the PolicyServiceRequestHandler maps with the PolicyRequest XML element in Figure 3.

!policy.JPG! Figure 9 width='400'

h4. 9.0 Federation Services

Figure 10 illustrates the concepts common to all federation standards and how they interact with other FAM components:
!fed.JPG! Figure 10' width='400'

The following Web single sign-on protocols are implemented :
* SAML1.1
* ID-FF 1.2
* SAML 2.0
* WS-Federation 1.1

Following Web Service standards are provided :
* ID-WSF 1.1
* WS-Security (WS-I BSP).

\[[#6]\] provides a complete list of use cases applicable to federation services.

Virtual Federation is a recently added feature of FAM. Virtual Federation addresses two key issues in deploying federation : (i) more than one federation standard in a Circle of Trust and (ii) legacy applications and existing authentication mechanisms. Using off the shelf simple http POST and data signing, legacy applications can *push* authentication and attribute information to a local FAM instance acting as an IDP that in turn can be communicated to remote partner aplications (SPs) via standard federation protocols listed above.

h4. 10.0 Agents

Agents are based on FAM client APIs - they are designed to protect web resources with no code changes to the resource business logic. Based on the standard 'interceptor' design pattern, agents intercept each incoming request and perform the necessary security check (authentication, authorization and auditing) before allowing control to be passed on to the protected resource. Agents for Java EE containers are based on Servlet filter and JSR 196 specs. Other containers, such as Apache, IIS, PeopleSoft, SAP, etc are based on proprietary interfaces provided by each. One of the key design goals of agents is to be transparent to the protected resource and as a result provide information about the authenticated user in the native form - such as a JAAS Subject for Java EE containers, REMOTE_USER for Apache, etc.

h4. 12.0 References :

\*{anchor:1}[#1] OpenSSO : [Conceptual Architecture|https://opensso.dev.java.net/servlets/ProjectDocumentList?folderID=4019&expandFolder=4019&folderID=4018] \| [Use cases|https://opensso.dev.java.net/servlets/ProjectDocumentList?folderID=6337&expandFolder=6337&folderID=7017]
\*{anchor:2}[#2] Access Manager : [Technical Overview|http://docs.sun.com/app/docs/doc/819-4669] \| [Product Documentation|http://docs.sun.com/app/docs/coll/1292.2]
\*{anchor:3}[#3] [Java EE Architecture|http://java.sun.com/javaee/]
\*{anchor:4}[#4] Standards : [OASIS (SAMLv1.1, v2)|http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security] \| [Liberty Alliance|http://dsame.red.iplanet.com/projects/6.2/documents/liberty/09-22-2003/] \| [WS-Security|http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss] \| [WS-Trust|http://msdn2.microsoft.com/en-us/library/ms951260.aspx] \| [WS-Federation|http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf]
\*{anchor:5}[#5] FAM DTDs IDRepo XSD: See Appendix A.
\*{anchor:6}[#6] [Federation Use cases|https://opensso.dev.java.net/servlets/ProjectDocumentList?folderID=6337&expandFolder=6337&folderID=7017]
\*{anchor:7}[#7] [JES Monitoring|http://docs.sun.com/app/docs/doc/819-5081/6n76iq54g#hic]

{anchor:ExportedInterfaces}

h4. Appendix A : Exported Interfaces

Please note : Only Interfaces marked * are public - others are private.
| __Service/Component__ | __API Reference__ | __SPI Reference__ | __Protocol__ | __Configuration__ |
| Naming | [WebtopNaming|^WebtopNaming.html] | N/A | [NamingRequest.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/NamingRequest.dtd?content-type=text/plain&rev=1.1], \\ [NamingResponse.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/NamingResponse.dtd?content-type=text/plain&rev=1.1] | [amNaming.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amNaming.xml?rev=1.1&view=log] |
| Flatfile : AMConfig | [SystemProperties|http://docs.sun.com/source/819-4682/com/iplanet/am/util/SystemProperties.html] | N/A | N/A | [^AMConfig.properties] |
| Flatfile : serverconfig.xml | [ServerConfigMgr|^ServerConfigMgr.html] | N/A | N/A | [serverconfig.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/serverconfig.xml?rev=1.10], [server-config.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/server-config.dtd?content-type=text/plain&rev=1.1] |
| \* CLI : amadm | [usage|^sample_cli.txt] | N/A | N/A | N/A |
| \* CLI : fmadm | [usage|^sample_cli.txt] | N/A | N/A | N/A |
| \* Admin Console | [UI Overview|http://docs.sun.com/app/docs/doc/819-4670/6n6qardt0?a=view] | [Customizing|http://docs.sun.com/app/docs/doc/819-4675/6n6qfk0pv?a=view] | Standard browser | [amConsoleConfig .xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/console/amConsoleConfig.xml?content-type=text%2Fplain&rev=1.3] \\ [amAccessControl.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/console/amAccessControl.xml?content-type=text%2Fplain&rev=1.4] |
| PLL | [Request|^Request.html] \\ [Response|^Response.html] \\ [Notification|^NotificationHandler.html] | [RequestHandler|^RequestHandler.html] \\ [NotificationHandler|^NotificationHandler.html] | [^PLLRequest.dtd] \\ [^PLLResponse.dtd] \\ [^PLLNotification.dtd] |
| SMS | [com.sun.identity.sm|http://docs.sun.com/source/819-4682/com/sun/identity/sm/package-summary.html] | [com.sun.identity.sm .SMSObjectDB|^SMSObjectDB.html] \\ | [IdentityManagementServices. wsdl|^IdentityManagementServices.wsdl] | [sms.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/sms.dtd?content-type=text/plain&rev=1.2] , \\ [smsflatfile.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/smsflatfile.dtd?content-type=text/plain&rev=1.1] |
| \* IdRepo | [com.sun.identity.idm|http://docs.sun.com/source/819-4682/com/sun/identity/idm/package-summary.html] | [com.sun.identity.idm .IdRepo|^IdRepo.html] \\ | [IdentityManagementServices. wsdl|^IdentityManagementServices.wsdl] | [idRepoDefaults.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/idRepoDefaults.xml?content-type=text/plain&rev=1.4] , \\ [idRepoService.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/idRepoService.xml?rev=1.8&view=log] |
| \* Logging | [com.sun.identity.log|http://docs.sun.com/source/819-4682/com/sun/identity/log/package-summary.html] | [com.sun.identity.log.spi|http://docs.sun.com/source/819-4682/com/sun/identity/log/spi/package-summary.html], \\ [java.util.logging|http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/package-summary.html] \\ [Authorizer|^IAuthorizer.html] \\ [TimestampGenerator|^ITimestampGenerator.html] | [LogDTD.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/logDTD.xml?content-type=text/plain&rev=1.1] | [amLogging.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amLogging.xml?rev=1.4&view=log] |
| Debug | [Debug|http://docs.sun.com/source/819-4682/com/iplanet/am/util/Debug.html] | | | [debug.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/debug.xml?rev=1.2] |
| \* Authentication | [com.sun.identity.authentication|http://docs.sun.com/source/819-4682/com/sun/identity/authentication/package-summary.html] | [com.sun.identity.authentication.spi|http://docs.sun.com/source/819-4682/com/sun/identity/authentication/spi/package-summary.html] | [remote-auth.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/remote-auth.dtd?content-type=text/plain&rev=1.3] | [Auth_Module_Properties.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/Auth_Module_Properties.dtd?content-type=text/plain&rev=1.2], [auth-schema.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/auth-schema.xml?content-type=text/plain&rev=1.2] ,[amAuth.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amAuth.xml?rev=1.5&view=log] |
| \* Session | [com.iplanet.sso|http://docs.sun.com/source/819-4682/com/iplanet/sso/package-summary.html] | [AMSessionRepository|^FAMSessionRepository.html] \\ [QuotaExhaustionAction|^QuotaExhaustionAction.html] | [SessionRequest.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/SessionRequest.dtd?content-type=text/plain&rev=1.1] , \\
[SessionResponse.dtd | https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/SessionResponse.dtd?content-type=text/plain&rev=1.1] , \\ [SessionNotification.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/SessionNotification.dtd?content-type=text/plain&rev=1.1] | [amSession.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amSession.xml?rev=1.1&view=log] |
| \* Policy | [com.sun.identity.policy|http://docs.sun.com/source/819-4682/com/sun/identity/policy/package-summary.html], \\ [com.sun.identity.policy.client|http://docs.sun.com/source/819-4682/com/sun/identity/policy/client/package-summary.html], \\ [com.sun.identity.policy.jaas|http://docs.sun.com/source/819-4682/com/sun/identity/policy/jaas/package-summary.html] | [com.sun.identity.policy.interfaces|http://docs.sun.com/source/819-4682/com/sun/identity/policy/interfaces/package-summary.html] | [remoteInterface.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/remote-auth.dtd?content-type=text/plain&rev=1.3] \\ | [Policy.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/policy.dtd?content-type=text/plain&rev=1.1] , \\ [PolicyAdmin.dtd|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/amserver/xml/dtd/policyAdmin.dtd?content-type=text/plain&rev=1.2], \\ [amPolicyConfig.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amPolicyConfig.xml?rev=1.2&view=log], \\ [amPolicy.xml|https://opensso.dev.java.net/source/browse/opensso/products/amserver/xml/services/amPolicy.xml?rev=1.5&view=log] |
| \* SAML2 | [com.sun.identity.saml2.assertion|http://docs.sun.com/source/819-5211/com/sun/identity/saml2/assertion/package-summary.html] \\ [com.sun.identity.saml2.common|http://docs.sun.com/source/819-5211/com/sun/identity/saml2/common/package-summary.html] \\ [com.sun.identity.saml2.protocol|http://docs.sun.com/source/819-5211/com/sun/identity/saml2/protocol/package-summary.html] | [com.sun.identity.saml2.plugins|http://docs.sun.com/source/819-5211/com/sun/identity/saml2/plugins/package-summary.html] | SAMLv2 specs \[[#4]\] | [fmCOTConfig.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmCOTConfig.xml?content-type=text%2Fplain&rev=1.2] \\
[fmSAML2.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmSAML2.xml?content-type=text%2Fplain&rev=1.1],[fmSAML2SOAPBinding.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmSAML2SOAPBinding.xml?content-type=text%2Fplain&rev=1.1], [fmSOAPBinding.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmSOAPBinding.xml?content-type=text%2Fplain&rev=1.2] |
| \* ID-FF | [com.sun.liberty|http://docs.sun.com/source/819-4682/com/sun/liberty/package-summary.html], \\ [com.sun.identity.federation.services|http://docs.sun.com/source/819-4682/com/sun/identity/federation/services/package-summary.html] | [com.sun.identity.federation.services|http://docs.sun.com/source/819-4682/com/sun/identity/federation/services/package-summary.html] | Liberty ID-FF \[[#4]\] | [fmIDFF.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmIDFF.xml?content-type=text%2Fplain&rev=1.1] |
| \* SAML1.1 | [com.sun.identity.saml|http://docs.sun.com/source/819-4682/com/sun/identity/saml/package-summary.html], \\ [com.sun.identity.saml.assertion|http://docs.sun.com/source/819-4682/com/sun/identity/saml/assertion/package-summary.html], \\ [com.sun.identity.saml.common|http://docs.sun.com/source/819-4682/com/sun/identity/saml/common/package-summary.html], \\ [com.sun.identity.saml.protocol|http://docs.sun.com/source/819-4682/com/sun/identity/saml/protocol/package-summary.html] | [com.sun.identity.saml.plugins|http://docs.sun.com/source/819-4682/com/sun/identity/saml/plugins/package-summary.html], \\ [com.sun.identity.saml.xmlsig|http://docs.sun.com/source/819-4682/com/sun/identity/saml/xmlsig/package-summary.html] | SAML 1.1 Specs \[[#4]\] | [fmSAML.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmSAML.xml?content-type=text%2Fplain&rev=1.1] |
| \* Liberty \\
Web Services | [com.sun.identity.liberty.ws.authnsvc|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/authnsvc/package-summary.html], \\ [com.sun.identity.liberty.ws.authnsvc. protocol|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/authnsvc/protocol/package-summary.html] , \\ [com.sun.identity.liberty.ws.disco|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/disco/package-summary.html], \\ [com.sun.identity.liberty.ws.dst|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/dst/package-summary.html], \\ [com.sun.identity.liberty.ws.interaction|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/interaction/package-summary.html] , \\ [com.sun.identity.liberty.ws.paos|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/paos/package-summary.html] | [com.sun.identity.liberty.ws.authnsvc. mechanism|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/authnsvc/mechanism/package-summary.html], \\ [com.sun.identity.liberty.ws.disco.plugins|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/disco/plugins/package-summary.html] , \\ [com.sun.identity.liberty.ws.dst.service|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/dst/service/package-summary.html], \\ [com.sun.identity.liberty.ws.idpp.plugin|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/idpp/plugin/package-summary.html], \\ [com.sun.identity.liberty.ws.interfaces|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/interfaces/package-summary.html], \\ [com.sun.identity.liberty.ws.security|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/security/package-summary.html], \\ [com.sun.identity.liberty.ws.soapbinding|http://docs.sun.com/source/819-4682/com/sun/identity/liberty/ws/soapbinding/package-summary.html] | Liberty ID-WSF \[[#4]\] | [fmLibertyPersonalProfile.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmLibertyPersonalProfile.xml?content-type=text%2Fplain&rev=1.1], \\ [fmSOAPBinding.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmSOAPBinding.xml?content-type=text%2Fplain&rev=1.2], \\ [fmAuthnSvc.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmAuthnSvc.xml?content-type=text%2Fplain&rev=1.2], \\ [fmDisco.xml|https://opensso.dev.java.net/source/browse/*checkout*/opensso/products/federation/openfm/xml/fmDisco.xml?content-type=text%2Fplain&rev=1.3] |
| \* Web Services | [com.sun.identity.wss.security|http://docs.sun.com/source/819-4682/com/sun/identity/wss/security/package-summary.html] | [com.sun.identity.wss.provider|http://docs.sun.com/source/819-4682/com/sun/identity/wss/provider/package-summary.html], \\ [com.sun.identity.wss.security.handler|http://docs.sun.com/source/819-4682/com/sun/identity/wss/security/handler/package-summary.html] | WS-\* specs \[[#4]\] |
| \* Agent Configuration \\ | Installer, Configuration of agent(s) provided by CLI/Console above. | [N/A\\|http://docs.sun.com/source/819-4682/com/sun/identity/wss/provider/package-summary.html] | \\ |

h4. Appendix B : Imported Interfaces

| __Interface Name__ | __Purpose__ |
| [JDK 1.5|http://java.sun.com] | Java Development Kit |
| [Java Cryptography Extension (JCE)|http://java.sun.com/products/jce/] | Encryption, digital signng, digests, crypto stuff |
| [Java Architecture for XML Bindng (JAXB) 1.0.6|http://java.sun.com] | XML processing :Marshal Java objects into XML and to unmarshal XML back into Java objects. |
| [SOAP with Attachment API for Java(SAAJ) 1.3|http://java.sun.com] | To send XML documents over SOAP from Java |
| [Java API for XML based RPC(JAX-RPC) 1.1.2|http://java.sun.com] | Java APIs for XML based RPC |
| [Java Mail Runtime(JMAIL) 1.3.2|http://java.sun.com] | Platform-independent and protocol-independent framework to build mail and messaging applications. |
| [LDAP JDK 4.17|http://www.mozilla.org/directory/javasdk.html] | Mozilla Directory SDK for Java - used to access LDAP directory. |
| [Java Studio Enterprise Web Application Framework(JATO) 1.1.5|] | Web application development framework - use to build console UI and authentication pages |
| [XML and Web Services Security|http://java.sun.com] | XWS-Security api to secure (digitally sign and encrypt) SOAP messages |
| [JES MF Instrumentation Toolkit (JESMF 2.0)|http://docs.sun.com/app/docs/doc/819-4669/6n6q9stcb?a=view] | Monitoring framework used for JMX based monitoring of FAM components |
| [SleepyCat Berkeley DB|http://www.oracle.com/technology/software/products/berkeley-db/db/index.html] | Persistent store for Session failover |
| [Sun Directory Server 5.2|http://docs.sun.com/app/docs/coll/S1_DirectoryServer_52] | LDAP server for configuration, authentication and user repository. \\
[Password Policy|http://docs.sun.com/source/816-6699-10/confattr.html#18722] when Sun DS is used for authentication. |
| [Active Directory|] | Supported LDAP server for both configuration, authentication and user repository. |
| [Sun Web Server 6.1|http://www.sun.com/software/products/web_srvr/home_web_srvr.xml] | Java container for FAM server, agent for protecting hosted applications |
| [Sun Application Server 8.x,9.x|http://java.sun.com/javaee/] | Java EE container for FAM server, agent for protecting hosted applications |
| [Weblogic Appplication Server 8.x,9.x|http://www.bea.com] | Java EE container for FAM server, agent for protecting hosted applications |
| [IBM Websphere Application Server 6.x|http://www.ibm.com] | Java EE container for FAM server, agent for protecting hosted applications |
| Operating Systems | FAM is supported on the following : \\
\* Sun Solaris 9.x, 10.x Sun Solaris 8, 9, and 10 for UltraSPARC systems \\
\* Sun Solaris 9 and 10 Operating Systems for x64/x86 systems \\
\* Windows Server 2003 and Windows XP (development only) \\
\* Red Hat Enterprise Linux AS/ES 2.1 and 3.0 \\
\* HPUX 11i |