Access Manager 7.1, Webserver 7.0 and Policy Agent 2.2 Logging behaviour

Hi,
I have a cluster setup with access manager (2 instances currently). I have a single webserver running access manager policy agent which points to the access manager cluster. Everything works fine, until the Agent session times out, whereupon it can no longer log to the access manager cluster.
i.e. it attempts to write a log entry like this:
2009-04-23 15:40:10.491 Debug 7720:2e7af0 LogService: BaseService::doRequest(): Using server: https://
am.blah.com:443/amserver/loggingservice.
<logRecWrite reqid="57"><log logName="amAuthLog.webserver.blah.com.80" sid="AQIC5wM2LY4SfczdB
6jEQSaqXL52vqgWNfqxVOf2teEx+b0=@AAJTSQACMTEAAlNLAAk0OTA4MTcyMzQAAlMxAAIwMg==#"></log><logRecord><level>8
00</level><recMsg>VXNlciBtb21lcjEgd2FzIGFsbG93ZWQgYWNjZXNzIHRvIGh0dHA6Ly9lcTAwMXRtLmVxLnNlcnZlci1jb21wbG
V4LmNvbTo4MC91d2MvaW5kZXguanNwLg==</recMsg><logInfoMap><logInfo><infoKey>LoginIDSid</infoKey><infoValue>
AQIC5wM2LY4Sfcy3bA/gJl2v7ArZCHla8Bj9bRVx4P6nSN0=@AAJTSQACMTEAAlNLAAstMTAxNzc2NjM2NQACUzEAAjAx#</infoValu
e></logInfo></logInfoMap></logRecord></logRecWrite>]]></Request>
</RequestSet>
and receives an error as follows:
2009-04-23 15:40:10.631MaxDebug 7720:2e7af0 LogService: <?xml version="1.0" encoding="UTF-8" standalone=
"yes"?>
<ResponseSet vers="1.0" svcid="iplanet.webtop.service.logging" reqid="74">
<Response><![CDATA[UNAUTHORIZED]]></Response>
</ResponseSet>
Investigation in the access manager logs shows that the agent session is no longer valid. As a result, I have two questions:
1. How can I make it stop trying to log remotely ? I have this set in the AMAgent.properties: com.sun.am.log.level = all:4
2. How do I exclude agents from the default session expiry times ?
Regards,
Michael Ward.

1. Set com.sun.am.policy.agents.config.audit.accesstype = LOG_NONE
2. Not sure if I understand this. Typically agent itself has to authenticate with the server and that agent session doesn't get expire anytime soon.
-Subba

Similar Messages

Oracle Identity and Access Management (11.1.1.3.0) and IM difference?

What is difference between Oracle Identity and Access Management (11.1.1.3.0) and Identity Management (11.1.1.3.0) ?
From
http://www.oracle.com/technetwork/middleware/downloads/oid-11g-161194.html

When you run the config, you are asked to add some product. Have checked the "Oracle Access Manager with Database Policy Store" product?
If not, you can add it by extending the domain. Once done you have to start two WLS servers (AdminServer and oam_server1):
Start AdminServer with $DOMAIN/bin/startWebLogic.sh
Start oam_server1 with $DOMAIN/bin/startManagedWebLogic.sh oam_server1
It might be that oam_server1 asks for username and password. This is fine for the first time. During the first start the necessary directory structure is created. Once it came up and enters RUNNING state, kill it and create a file boot.properties in $DOMAIN/servers/oam_server1/security with the entries username=name and password=pw in two lines and start oam_server1 again.
Starting oam_server1 is recommend to get proper values in the oamconsole.
HTH,
--olaf

AppServer 9 and Policy Agent?

Hello reader!
I'm stuck with basics :(. Where is the documentation for Application Server 9 Policy Agent? How do I configure an application to login via Access Manager (for example Calendar Client from the Blueprints)?
I'm really lost right now, I find docs for Policy Agent on many App Servers, but not for App Server 9. What is it that I don't get?
Thanks for help!
Christoph

The link and excerpt below, from the docs, might supply info of interest. My entry just prior to this one is in reference to an earlier question in this thread.
http://docs.sun.com/app/docs/doc/820-2539/6ne4ra881?a=view#gbbip
Caution � Caution �
Once a J2EE agent is installed for a specific domain, the J2EE agent binaries cannot be used on that same Application Server installation for a different Application Server 9.0/9.1 domain. If you attempt to use previously installed J2EE agent binaries on the same Application Server installation, but on a different domain, the installation fails.
J2EE agents associate a specific set of agent binaries with a particular domain for Application Server 9.0/9.1. If you want to install a J2EE agent on a different domain, unzip a new set of bits and copy them to a separate location before running the agentadmin --install command for the second domain.

JAAS and Policy Agents

Hello everybody, I'm trying to create a simple JSP that it is protected using the Access Manager Policy Agent. I have configured the URL policy and it is working fine.
Now in my JSP I want to know what user is logged in but I don't want to use the AM API, instead I want to use the JAAS module. Any ideas on how to do it?
I thought thar AM will set the session attribute javax.security.auth.subject but I don't think it is doing it.
I get the Subject object but when calling the getPrincipals, the set is empty.
Any ideas?
Thanks a lot.

Easy way: Configure your agent to set the user ID in HTTP head so you can read it without touching AM API.
Tough way: Enable form based authentication, install AM J2EE Agent (not web policy agent), you can get user ID with "getPrincipals" or "getRemoteUser" method.
Keep in mind, Using JAAS module does not mean you can avoid AM API, but do you have other reason to use JAAS? I usually keep myself away from it.

ID Server and Policy Agent for AS .. is secure?

Hello there,
I have a question. Quite critical question, concerning iPlanetDirectoryPro cookie. If I've got it right, this cookie contains SSO Token. And the SSO token can be used with identity server to obtain any SSO assetion. I've experimentaly confirmed this.
Now, can anyone tell me why this cookie is sent to any host in my domain? The default after instalation is "bgs.sk". This default value enables any host in my domain to impersonate me. Well, I still can change this, but it is now good to have insecure default values anyway, is it?
Second, and more critical problem: I have Policy Agent installed on my Application Server. It looks like the agent requires access to the iPlanetDirectoryPro cookie to work correctly. But, if my application server has my SSO token, it can impersonate me anywhere. Not a good situation at all. That would mean security hole as big as hangar doors.
Are my assumptions correct? Am I overlooking something?
(All valid for ID server 6.0 and Liberty protocols)
Thanks for any help.

Although Sun promote Identity Server by emphasizing its Liberty/SAML feature, the product itself use a proprietary protocol for SSO and CDSSO.
As all we know, this product could be totally useless without Sun's Policy/J2EE Agent deployed. But ironically these agents communicate with Identity Server in its own way, nothing to do with SAML, XACML, or even SOAP.
The agent approach is usually not a good idea. We saw more and more problem raised from fields related to agent stability and scalability. We never see any performance benchmark data from Sun. Since the communication between agt and Identity Server are proprietary, no ISV can make agent for this product. You have to wait for Sun for agent support if you have new system not on the support matrix.
In addition to agent, another big issue of Identity Server is its complex DIT structure. In fact, we prefer to have RDBMS as Identity Server's repository. Sun abuse ldap just because this company doesn't have any database product but still want to provide a pure Sun platform (JES) to customer. So they compromise the architecture for business reason, I'd like to tell you, I don't like the way Identity Server store data in DIT, I don't like the console UI (its for technical geek), and on one in our company dare to do any configuration change.
Now Sun put Identity Server as the core of its JES product stack. If you have time to take a look at how the SJS Portal use Identity Server and how SSO between Portal channel and Email/Calendar Server are achieved, you'll find that you just buy a "framework" (I mean Identity server), not a product, because you have to do every integration work by intensively coding.
I predict that Identity Server will be significantly rearchitctured in the near future, otherwise we don't see any benefit this product can bring to me. It is a headache for deployment as well as maintenance. If you just need Single Sign-On, there are lots alternative to achieve, Sun's Identity Server is really overkill. It's authentication feature is ok, but authorization feature (policy, role) is very limited. If you have lots of Windows/IIS web app need to do SSO with Identity Server, god bless you... you better have a sharp programmer to wrap up the C API so as your ASP programmer can leverage Identity Server SDK, and you got to pray for IIS agent behave well. In addition, don't forget to learn more about JATO if you want to do some fancy customization on the default login page.

Appserver and policy agent

Hi,
I want to protect a folder under the docroot of the application server for access only by a certain ldap group. It's just a folder, not a web application. Is this possible with the policy agent? If so, how? There's no web.xml or so ... .
Right now I have installed the agent, but it is not applying my url policy.
Any info is welcome.
Regards,
Tim

this should work. you only need the web.xml bit if you want to evaluate policies and pass/propagate j2ee auth tokens to AM. to authenticate ldap groups only, you can just use the urlpolicy agent in sso only mode.

I am trying to launch my external hard drive through maxtor central access manager. It will not launch and I keep receiving a KERN_PROTECTION_FAILURE error. Through discussion threads, it sounds like it may be a disk utility, repair issue. Please advis

I navigated to disk utility and verified disk, which returned no errors.

I'm not sure what you mean when you say that you're "trying to launch" an external hard drive, but you don't need Maxtors software to mount it on the desktop. Is this a new drive? Have you formatted it using Disk Utility?

Policy Agent doesn't reset Sun Access Manager session time idle value

Hi,
We have the following setup in our environment:
- apache web server/web and policy agent 2.2 for apache 2.0.54
- webmethods portal server (jetty)
-Sun Access Manager (with Sun Directory Server)
We use policy agent for authentication purpose only (via Sun Access Manager/LDAP) when the users access the portal. We have custom code that creates session in Sun Access Manager for custom LDAP services. For testing purpose, we configure SAM session to have Max Session Timeout at 120mins and Time Idle at 15mins. I would assume that, after the initial login request, for all subsequent accesses to the portal the policy agent should intercept the request and reset the Time Idle value of SAM session. However, when I monitor time idle value using SAM console, session tab, the time idle value didn't change when the portal user access pages, submit actions, etc. I can see in the debug log of policy agent that requests are being intercepted/processed, but the time idle didn't get reset.
Does anyone know if this is a bug in configuration or in policy agent itself or am I making the wrong assumption?
Thanks a lot for the help.

Thanks for the reply, Shivaram. The issue appears to occur at random time, not accurately at the 3 min interval as you mention. I tested changing this value to 1, theoretically, after one 1 minute of idle time, accessing a link would make the agent reset the time idle value for the user session in SAM, but it didn't even after 3 minutes. This seems to be either a policy agent or system access manager bug.
We performed a 'vanilla' test using the apache server manual pages (only plain HTML, no POST requests), the pages are protected by the policy agent. At the first login, rwe were prompted to enter credential to be validated by SAM/LDAP, and then a user session is created in SAM session table. We browse around the manual pages, once in a while, certain pages cause the policy agent to reset the time idle. However, revisiting these links after a few minutes doesn't reset the idle value. Caching setting has been disable as well. Could there be or lack of some settings in AMConfig.properties or AMAgent.properties that might have caused this behavior?
Thanks for all your help,

UWC/CE 6.3 and Access Manager 7.1 SSO sometimes fails (seems like a bug)

PREAMBULA: I started writing this post thinking that our AM SSO setup was at fault in some step. As I was gathering data, checking the doc-links and config files and finally sniffed the servers for HTTP dialogs, I grew pretty sure there's a bug in UWC/CE, AM SDK or Web Server Policy Agent, whatever implements the AM SSO session checking.
In short, as written below, our "sunmail" server can POST a broken cookie to AM server, if the cookie originally contained a "plus" character. The "plus" is replaced by a "space", invalidating the session check. As we know, "+" is often used in URLs to "escape" the space character. Perhaps some URL cleanup routine backfired here. I have double-checked, it is not the reverse proxy on "psam" breaking things. It is "sunmail" (UWC/CE or Policy Agent, don't know for certain) supplying the broken request. On the few occasions when the AM cookie contains no "plus" characters, the SSO works like a charm (also checked by a sniffer). Whenever there is a "plus", it breaks.
Is there some known bug or workaround that matches this description?
Nevertheless, for completeness' sake I kept the description of our setup. Maybe it's at fault after all :)
We have an installation of JCS5 with the latest patches as of early July 2008. And as the subject implies, we have problems with AM SSO in UWC/CE web-interface. I have reported them before, then they seemed fixed (not occuring for several tests in a row), but as time has shown, something wrong is still there.
So I'll try to go into deeper detail now, as we've may have overlooked some nuance... Then again, as my sniffer research below shows, this may be an engine bug and these setup details are irrelevant.
Our setup is split into several Solaris 10 full-root zones hosted on several servers, some of the components are enroute to HA (perhaps we made some mistakes on this part of the way?)
So, we have the following software stack:
1) two MMR Directory Servers (DSEE 6.3 = DSEE 6.2 from JCS5 + 125278-07__DSEE_6.3__x86x64 + 125277-07__DSEE_6.3__x86_sol9 patches) working in zones on two different servers. Except for one time when a manually forced ZFS rollback corrupted one of the server instances, no problems here.
2) two zones with Directory Proxy Servers (6.3, exact versions as above) running at port 389 provide the clients with an illusion that they have a stable Directory Server, even if one of the actual servers is currently rebooting ;)
These DPS zones are hosted on two different servers as well and are primarily used by LDAP clients (JCS components) running in other zones on the same respective servers.
3) A zone with Sun Web Server 7.0U1 and Access Manager 7.1 (+ 126357-01__AM71_x86 patch) and Delegated Admin 6.4-4.01 (from JCS5 + 121582-18__COMMCLI64__x86 patch).
At the moment there is one such zone (named "cos-psam-01.domain.ru" in the logs below), but we expect(-ed) it to become two similar zones as per AM HA setup.
Zones listed in (1-3) use private IP numbers, they belong in our internal DMZ.
Zones listed in (4-5) below use public (routed) IP numbers, they belong in our external DMZ.
4) A zone with Sun Web Server 7.0U1 used primarily as a reverse-proxy server (optionally with a load-balancer libpassthrough.so plugin) successfully used for other hosted projects. One of its configurations now passes connections from an externally routed IP address published as "psam.domain.ru" to "cos-psam-01.domain.ru", per AM HA setup, so HTTP clients believe they work with an Access Manager instance. This zone has a backend interface with a private IP address to communicate with the actual AM instance.
In AM configuration (both LDAP and file-based) we have configured a site ID with the publicly known name and mentioned both names (psam and cos-psam-01) in organization's realm/dns aliases.
5) A zone with the rest of the Sun Java Communications Suite 5, as in Messaging Server 6.3 (6.3-6.03 64-bit: ci-5.0-1.03_solx86_x64__Messaging_Server_6.3-2 + patch 126480-09__MSG63__x86-64), UWC/CE 6.3 (from JCS5 + 122794-17__UWC63-4.01_core__x86), Instant Messaging 7.2 (from JCS5 + 118790-29__IM72__x86-1 + 118787-28__IM72__x86-2), Calendar Server 6.3 (from JCS5 + 121658-28__iCS63__x86). The web-components (UWC/CE, IM, /httpbind) are deployed in a Sun Web Server 7.0U1 as well.
This zone is named "sunmail.domain.ru" and has a routed IP address for direct external access to its servicess.
The AM SDK part is also patched (126357-01__AM71_x86); it points to the load-balancer name ("psam.domain.ru") as an actual AM server.
# imsimta version
Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 64bit)
libimta.so 6.3-6.03 (built 17:15:08, Mar 14 2008; 64bit)
SunOS sunmail 5.10 Generic_127112-07 i86pc i386 i86pc
While setting up this server set we tried to use AM SSO as the user login method, but it works unreliably.
"Unreliably" means that while most of the time entering a correct uid and password in Access Manager login page ("http://psam.domain.ru/amserver/UI/Login") does redirect a user back to "http://sunmail.domain.ru/uwc/auth" along with a new cookie, and the user is redirected again to his or her mailbox, sometimes the user receives the UWC/CE login page. Entering the same uid and password here does log him in, but it breaks the whole point of SSO and only increases the end-user routine required to log in :\
We have also seen the "missing mail tab" problem - if the users point the browser to any hostname different from "sunmail.domain.ru" (i.e. www.mail.domain.ru which is equivalent in DNS), they have only the Address book, Calendar and Options tabs; no webmail. So far this is resolved by Policy Agent forcing The One name of the server.
Here's the configuration we did specifically for AM SSO:
1) in AMConfig.properties of "sunmail" and "cos-psam-01" we set up
com.iplanet.am.cookie.encode=false
am.encryption.pwd=<the same value>
all hostname-related parameters point to "psam.domain.ru"
2) in AMConfig.properties of "cos-psam-01" a number of FQDN equivalence entries are added (so it does not redirect to a server hostname unknown to visitors):
com.sun.identity.server.fqdnMap[publicname-or-ip]=psam.domain.ru
com.sun.identity.server.fqdnMap[cos-psam-01.domain.ru]=cos-psam-01.domain.ru
3) in "msg.conf" on "sunmail" (entries added via configutil):
local.webmail.sso.amcookiename = iPlanetDirectoryPro
local.webmail.sso.amnamingurl = http://psam.domain.ru:80/amserver/namingservice
local.webmail.sso.singlesignoff = yes
local.webmail.sso.uwcenabled = 1
service.http.ipsecurity = no
(perhaps some more options are required? Looking for confirmation about: local.webmail.sso.uwclogouturl local.webmail.sso.uwccontexturi local.webmail.sso.uwchome service.http.allowadminproxy )
4) Configured Web Policy Agent for Sun Web Server, so that users without an AM session are required to get one. Set up per [http://msg.wikidoc.info/index.php/AM_redirection_using_Policy_Agent], except that com.sun.am.policy.agents.config.notenforced_list points to the many names our server can go known by.
5) Updated the logout URL in /opt/SUNWuwc/webmail/main.js:
--- main.js.orig        Sat Jan 26 07:52:09 2008
+++ main.js     Mon Jul 21 01:06:29 2008
@@ -667,7 +667,8 @@
function cleanup() {
   if(laurel)
-      top.window.location = getUWCHost() + "/base/UWCMain?op=logout"
+//      top.window.location = getUWCHost() + "/base/UWCMain?op=logout"
+      top.window.location = "http://sunmail.domain.ru:80/base/UWCMain?op=logout"
   else
       exec('logout', '', 'exit()')
@@ -1707,7 +1708,8 @@
   if(lg) {
         url = document.location.href
         url = url.substr(0,url.indexOf('webmail'))
-        uwcurl = url + 'base/UWCMain?op=logout'
+//      uwcurl = url + 'base/UWCMain?op=logout'
+        uwcurl = "http://sunmail.domain.ru:80/base/UWCMain?op=logout"
   exit()
}6) Calendar SSO - per docs...
According to ngrep sniffing,
1) the browser goes to "http://sunmail.domain.ru/uwc/auth" without any cookies
2) receives a redirect and goes to "http://psam.domain.ru/amserver/UI/Login?gotoOnFail=http://sunmail.domain.ru:80/uwc&goto=http%3A%2F%2Fsunmail.domain.ru%3A80%2Fuwc%2Fauth"; sends no cookies either.
3) The first response from the "psam" server (as redirected from "cos-psam-01") sets a few cookies while rendering the login page:
Set-cookie: JSESSIONID=7EF8F2810D2071CA03CFEAE9972735B2; Path=/
Set-cookie: AMAuthCookie=AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#; Domain=.domain.ru; Path=/
Set-cookie: amlbcookie=02; Domain=.domain.ru; Path=/
4) The browser requests the login page resources (javascripts, images, etc) using these cookies, as in this header line:
Cookie: JSESSIONID=7EF8F2810D2071CA03CFEAE9972735B2; AMAuthCookie=AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#; amlbcookie=02
5) The browser POSTs the login request to "/amserver/UI/Login" and receives a redirection to http://sunmail.domain.ru:80/uwc/auth
Set-cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#; Domain=.domain.ru; Path=/
Set-cookie: AMAuthCookie=LOGOUT; Domain=.domain.ru; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
6) The browser requests "http://sunmail.domain.ru/uwc/auth" using the newly set cookie (looks like the old one to me though):
Cookie: amlbcookie=02; iPlanetDirectoryPro=AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#
7) The "sunmail" web-server checks the AM session validity with the same "psam.domain.ru". It sends a series of POSTs to /amserver/namingservice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="com.iplanet.am.naming" reqid="685">
<Request><![CDATA[
<NamingRequest vers="1.0" reqid="324" sessid="AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#">
<GetNamingProfile>
</GetNamingProfile>
</NamingRequest>]]>
</Request>
</RequestSet>(receives a large XML list of different Access Manager configuration parameters and URLs)
...then a double-request to /amserver/sessionservice:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="Session" reqid="686">
<Request><![CDATA[
<SessionRequest vers="1.0" reqid="678">
<GetSession reset="true">
<SessionID>AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#</SessionID>
</GetSession>
</SessionRequest>]]>
</Request>
<Request><![CDATA[
<SessionRequest vers="1.0" reqid="679">
<AddSessionListener>
<URL>http://sunmail.domain.ru:80/UpdateAgentCacheServlet?shortcircuit=false</URL>
<SessionID>AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1+xTqH7C3I=@AAJTSQACMDI=#</SessionID>
</AddSessionListener>
</SessionRequest>]]>
</Request>
</RequestSet>As a result it receives an XML with a lot of user-specific information (the username, LDAP DN, preferred locale, auth module used, etc.)
!!!*** Now, the problem part ***!!!
8) And then "sunmail" POSTs a broken cookie to "psam" (note the space in mid-text, where the "plus" sign was previously). As we know, "+" is often used in URLs to "escape" the space character. Perhaps some URL cleanup routine backfired here.
I have double-checked, it is not the reverse proxy on "psam" breaking things. It is "sunmail" (UWC/CE or Policy Agent, don't know for certain) supplying the broken request. I looked over the large XML responses to the two previous requests, whenever they mention the session cookie value, the "plus" is there.
For the most detail I can provide, I'll even paste the whole HTTP packet:
POST /amserver/sessionservice HTTP/1.1
Proxy-agent: Sun-Java-System-Web-Server/7.0
Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1 xTqH7C3I=@AAJTSQACMDI=#;amlbcookie=null
Content-type: text/xml;charset=UTF-8
Content-length: 336
Cache-control: no-cache
Pragma: no-cache
User-agent: Java/1.5.0_09
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Host: cos-psam-01.domain.ru
Client-ip: 194.xxx.xxx.xxx
Via: 1.1 https-weblb.domain.ru
Connection: keep-alive
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="session" reqid="258">
<Request><![CDATA[<SessionRequest vers="1.0" reqid="254">
<GetSession reset="true">
<SessionID>AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1 xTqH7C3I=@AAJTSQACMDI=#</SessionID>
</GetSession>
</SessionRequest>]]></Request>
</RequestSet> The server's error response is apparent:
HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Thu, 31 Jul 2008 05:49:50 GMT
Content-type: text/html
Transfer-encoding: chunked
19b
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="session" reqid="258">
<Response><![CDATA[<SessionResponse vers="1.0" reqid="254">
<GetSession>
<Exception>AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1 xTqH7C3I=@AAJTSQACMDI=# Invalid session ID
AQIC5wM2LY4SfcwuT2ASCrsfO78nXdceEHXeH1 xTqH7C3I=@AAJTSQACMDI=#</Exception>
</GetSession>
</SessionResponse>]]></Response>
</ResponseSet>On the few occasions when the AM cookie contains no "plus" characters, the SSO works like a charm (also checked by a sniffer). Whenever there is a "plus", it breaks.
For reference, here's a working final request-response (one with a good cookie, as received by the load-balancer web-server). Request looks a bit different:
POST /amserver/sessionservice HTTP/1.1
Cookie: iPlanetDirectoryPro=AQIC5wM2LY4Sfcy/5sEzVmuq9z1ggdHOkBDgVFAwfhqvn4U=@AAJTSQACMDI=#;amlbcookie=null
Content-Type: text/xml;charset=UTF-8
Content-Length: 379
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.5.0_09
Host: psam.domain.ru
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RequestSet vers="1.0" svcid="session" reqid="281">
<Request><![CDATA[<SessionRequest vers="1.0" reqid="277">
<SetProperty>
<SessionID>AQIC5wM2LY4Sfcy/5sEzVmuq9z1ggdHOkBDgVFAwfhqvn4U=@AAJTSQACMDI=#</SessionID>
<Property name="uwcstatus" value="active"></Property>
</SetProperty>
</SessionRequest>]]></Request>
</RequestSet> ...and the response is OK:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseSet vers="1.0" svcid="session" reqid="281">
<Response><![CDATA[<SessionResponse vers="1.0" reqid="277">
<SetProperty>
<OK></OK>
</SetProperty>
</SessionResponse>]]></Response>
</ResponseSet>

There have been a few reports of the same behaviour with other customers - specifically with the handling of the encoding of "+" characters to " ". It relates to how cookie encoding/decoding is performed (as you have already observed).
The solution for these customers was the following:
=> AM server/client side:
Ensure that com.iplanet.am.cookie.encode=false in AMConfig.properties and AMAgent.properties on all systems.
=> AM client (UWC) side:
- Set <property name="encodeCookies" value="false"/> in /var/opt/SUNWuwc/WEB-INF/sun-web.xml. This will prevent UWC from trying to urldecode the cookie it receives and therefore stops it turning the + into a space e.g.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 Servlet 2.3//EN' 'file:///net/wajra.india.sun.com/export/share/dtd/sun-web-app_2_3-1.dtd'>
<sun-web-app>
   <property name="encodeCookies" value="false"/>
   <session-config>
      <session-manager/>
   </session-config>
   <jsp-config/>
<property name="allowLinking" value="true" />
</sun-web-app>Regards,
Shane.

New Segment of Access Manager-Federation Manager FAQ on Liberty and SAML

Sun Developer Network just published a new segment of a Sun Java System Access Manager and Sun Java System Federation Manager FAQ on Liberty Alliance and Security Assertion Markup Language (SAML). See http://developers.sun.com/identity/overview/faq/libertysaml.jsp.
The Q&As also shed light on those products' support for identity-based services in Access Manager, on the utilities for creating and maintaining federated connections, on the components in Federation Manager, and on other related topics.

This may not be the same as the problem you are seeing, but I was recently struggling with debugging an SSL connection out of the amserver, and eventually noticed that the amserver uses its own protocol handler rather than the sun.net.www.protocol included in java 1.4 and above. My guess is that this is because the amserver is older than java 1.4 but I'm not sure, they may have some other reason for using their own implementation.
If you look at the web server server.xml after the amserver install, you will see a line like:
<JVMOPTIONS>-Djava.protocol.handler.pkgs=com.iplanet.services.comm</JVMOPTIONS>
if you replace that with:
<JVMOPTIONS>-Djava.protocol.handler.pkgs=sun.net.www.protocol</JVMOPTIONS>
you might get the pre-amserver behaviour that you are after. Basically all of the httpsURLConnection things behave subtly differently otherwise, as when getting a HttpsURLConnection you are getting a com.iplanet.services.comm.https.HttpsURLConnection rather than a sun.net.www.protocol.https.HttpsURLConnection as you might be expecting.

Difference: Oracle Access Manager and Oracle Access Management

Dear,
What is the difference between Oracle Access Manager and Oracle Access Management, both 11g
thanks

Oracle Access Manager is the foundation(main product), of the new Oracle Access Management platform. Access Manager provides the core functionality of Web Single Sign On(SSO), authentication, authorization, centralized policy administration and agent management, real-time session management and auditing. Built as a 100% Java solution, Access Manager is extremely scalable to handle Internet scale deployments and works with existing heterogeneous environments in the enterprise with agents certified on hundreds of web servers and application servers. Access Manager provides rich functionality, extreme scalability and high availability thereby increasing security, improving user experience and productivity and enhancing compliance while reducing total cost of ownership.
Oracle Access management solution provides: Comprehensive Web Access Management, Web Single Sign-On, Identity Propagation, and Federation;Mobile and Social Sign-On;Real-time External Authorization;daptive Access and Fraud Detection
So basically one is a product and the other one is an entire solution.
I hope this helps,
Thiago Leoncio.

SSL connection between Dist Auth UI Server and Access Manager

Hi,
I have a Dist Auth UI Server installed in Web Server 7 and working properly, but now i want to configure it to talk with Access Manager with a secure port.
I have configured Access Manager (also deployed in Web Server 7) in a secure port (443). I have requested and installed the server certificate in the Access Manager Web Server instance and also the root entity certificate.
My question is: how must i configure the UI Server to communicate with the Access Manager Server in a secure way and trust the certificate that the WS of the AM presents ?
Regards,

There have been a few reports of the same behaviour with other customers - specifically with the handling of the encoding of "+" characters to " ". It relates to how cookie encoding/decoding is performed (as you have already observed).
The solution for these customers was the following:
=> AM server/client side:
Ensure that com.iplanet.am.cookie.encode=false in AMConfig.properties and AMAgent.properties on all systems.
=> AM client (UWC) side:
- Set <property name="encodeCookies" value="false"/> in /var/opt/SUNWuwc/WEB-INF/sun-web.xml. This will prevent UWC from trying to urldecode the cookie it receives and therefore stops it turning the + into a space e.g.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 Servlet 2.3//EN' 'file:///net/wajra.india.sun.com/export/share/dtd/sun-web-app_2_3-1.dtd'>
<sun-web-app>
   <property name="encodeCookies" value="false"/>
   <session-config>
      <session-manager/>
   </session-config>
   <jsp-config/>
<property name="allowLinking" value="true" />
</sun-web-app>Regards,
Shane.

Too Slow - Domino 6.5.4 with access manager agent 2.2 ?

I don't know how to tune Domino 6.5.4 with access manager agent 2.2?
I think AMAgent.properties is not good for SSO.
Please help me to tune it.
# $Id: AMAgent.properties,v 1.103 2005/09/19 22:08:34 madan Exp $
# Copyright ? 2002 Sun Microsystems, Inc. All rights reserved.
# U.S. Government Rights - Commercial software. Government users are
# subject to the Sun Microsystems, Inc. standard license agreement and
# applicable provisions of the FAR and its supplements. Use is subject to
# license terms. Sun, Sun Microsystems, the Sun logo and Sun ONE are
# trademarks or registered trademarks of Sun Microsystems, Inc. in the
# U.S. and other countries.
# Copyright ? 2002 Sun Microsystems, Inc. Tous droits r閟erv閟.
# Droits du gouvernement am閞icain, utlisateurs gouvernmentaux - logiciel
# commercial. Les utilisateurs gouvernmentaux sont soumis au contrat de
# licence standard de Sun Microsystems, Inc., ainsi qu aux dispositions en
# vigueur de la FAR [ (Federal Acquisition Regulations) et des suppl閙ents
# ? celles-ci.
# Distribu? par des licences qui en restreignent l'utilisation. Sun, Sun
# Microsystems, le logo Sun et Sun ONE sont des marques de fabrique ou des
# marques d閜os閑s de Sun Microsystems, Inc. aux Etats-Unis et dans
# d'autres pays.
# The syntax of this file is that of a standard Java properties file,
# see the documentation for the java.util.Properties.load method for a
# complete description. (CAVEAT: The SDK in the parser does not currently
# support any backslash escapes except for wrapping long lines.)
# All property names in this file are case-sensitive.
# NOTE: The value of a property that is specified multiple times is not
# defined.
# WARNING: The contents of this file are classified as an UNSTABLE
# interface by Sun Microsystems, Inc. As such, they are subject to
# significant, incompatible changes in any future release of the
# software.
# The name of the cookie passed between the Access Manager
# and the SDK.
# WARNING: Changing this property without making the corresponding change
# to the Access Manager will disable the SDK.
com.sun.am.cookie.name = iPlanetDirectoryPro
# The URL for the Access Manager Naming service.
com.sun.am.naming.url = http://sportal.yjy.dqyt.petrochina:80/amserver/namingservice
# The URL of the login page on the Access Manager.
com.sun.am.policy.am.login.url = http://sportal.yjy.dqyt.petrochina:80/amserver/UI/Login
# Name of the file to use for logging messages.
com.sun.am.policy.agents.config.local.log.file = c:/Sun/Access_Manager/Agents/2.2/debug/C__Lotus_Domino/amAgent
# This property is used for Log Rotation. The value of the property specifies
# whether the agent deployed on the server supports the feature of not. If set
# to false all log messages are written to the same file.
com.sun.am.policy.agents.config.local.log.rotate = true
# Name of the Access Manager log file to use for logging messages to
# Access Manager.
# Just the name of the file is needed. The directory of the file
# is determined by settings configured on the Access Manager.
com.sun.am.policy.agents.config.remote.log = amAuthLog.Dominoad.yjy.dqyt.petrochina.80
# Set the logging level for the specified logging categories.
# The format of the values is
#     <ModuleName>[:<Level>][,<ModuleName>[:<Level>]]*
# The currently used module names are: AuthService, NamingService,
# PolicyService, SessionService, PolicyEngine, ServiceEngine,
# Notification, PolicyAgent, RemoteLog and all.
# The all module can be used to set the logging level for all currently
# none logging modules. This will also establish the default level for
# all subsequently created modules.
# The meaning of the 'Level' value is described below:
#     0     Disable logging from specified module*
#     1     Log error messages
#     2     Log warning and error messages
#     3     Log info, warning, and error messages
#     4     Log debug, info, warning, and error messages
#     5     Like level 4, but with even more debugging messages
# 128     log url access to log file on AM server.
# 256     log url access to log file on local machine.
# If level is omitted, then the logging module will be created with
# the default logging level, which is the logging level associated with
# the 'all' module.
# for level of 128 and 256, you must also specify a logAccessType.
# *Even if the level is set to zero, some messages may be produced for
# a module if they are logged with the special level value of 'always'.
com.sun.am.log.level =
# The org, username and password for Agent to login to AM.
com.sun.am.policy.am.username = UrlAccessAgent
com.sun.am.policy.am.password = LYnKyOIgdWt404ivWY6HPQ==
# Name of the directory containing the certificate databases for SSL.
com.sun.am.sslcert.dir = c:/Sun/Access_Manager/Agents/2.2/domino/cert
# Set this property if the certificate databases in the directory specified
# by the previous property have a prefix.
com.sun.am.certdb.prefix =
# Should agent trust all server certificates when Access Manager
# is running SSL?
# Possible values are true or false.
com.sun.am.trust_server_certs = true
# Should the policy SDK use the Access Manager notification
# mechanism to maintain the consistency of its internal cache? If the value
# is false, then a polling mechanism is used to maintain cache consistency.
# Possible values are true or false.
com.sun.am.notification.enable = true
# URL to which notification messages should be sent if notification is
# enabled, see previous property.
com.sun.am.notification.url = http://Dominoad.yjy.dqyt.petrochina:80/amagent/UpdateAgentCacheServlet?shortcircuit=false
# This property determines whether URL string case sensitivity is
# obeyed during policy evaluation
com.sun.am.policy.am.url_comparison.case_ignore = true
# This property determines the amount of time (in minutes) an entry
# remains valid after it has been added to the cache. The default
# value for this property is 3 minutes.
com.sun.am.policy.am.polling.interval=3
# This property allows the user to configure the User Id parameter passed
# by the session information from the access manager. The value of User
# Id will be used by the agent to set the value of REMOTE_USER server
# variable. By default this parameter is set to "UserToken"
com.sun.am.policy.am.userid.param=UserToken
# Profile attributes fetch mode
# String attribute mode to specify if additional user profile attributes should
# be introduced into the request. Possible values are:
# NONE - no additional user profile attributes will be introduced.
# HTTP_HEADER - additional user profile attributes will be introduced into
# HTTP header.
# HTTP_COOKIE - additional user profile attributes will be introduced through
# cookies.
# If not within these values, it will be considered as NONE.
com.sun.am.policy.agents.config.profile.attribute.fetch.mode=NONE
# The user profile attributes to be added to the HTTP header. The
# specification is of the format ldap_attribute_name|http_header_name[,...].
# ldap_attribute_name is the attribute in data store to be fetched and
# http_header_name is the name of the header to which the value needs
# to be assigned.
# NOTE: In most cases, in a destination application where a "http_header_name"
# shows up as a request header, it will be prefixed by HTTP_, and all
# lower case letters will become upper case, and any - will become _;
# For example, "common-name" would become "HTTP_COMMON_NAME"
com.sun.am.policy.agents.config.profile.attribute.map=cn|common-name,ou|organizational-unit,o|organization,mail|email,employeenumber|employee-
number,c|country
# Session attributes mode
# String attribute mode to specify if additional user session attributes should
# be introduced into the request. Possible values are:
# NONE - no additional user session attributes will be introduced.
# HTTP_HEADER - additional user session attributes will be introduced into HTTP header.
# HTTP_COOKIE - additional user session attributes will be introduced through cookies.
# If not within these values, it will be considered as NONE.
com.sun.am.policy.agents.config.session.attribute.fetch.mode=NONE
# The session attributes to be added to the HTTP header. The specification is
# of the format session_attribute_name|http_header_name[,...].
# session_attribute_name is the attribute in session to be fetched and
# http_header_name is the name of the header to which the value needs to be
# assigned.
# NOTE: In most cases, in a destination application where a "http_header_name"
# shows up as a request header, it will be prefixed by HTTP_, and all
# lower case letters will become upper case, and any - will become _;
# For example, "common-name" would become "HTTP_COMMON_NAME"
com.sun.am.policy.agents.config.session.attribute.map=
# Response Attribute Fetch Mode
# String attribute mode to specify if additional user response attributes should
# be introduced into the request. Possible values are:
# NONE - no additional user response attributes will be introduced.
# HTTP_HEADER - additional user response attributes will be introduced into
# HTTP header.
# HTTP_COOKIE - additional user response attributes will be introduced through
# cookies.
# If not within these values, it will be considered as NONE.
com.sun.am.policy.agents.config.response.attribute.fetch.mode=NONE
# The response attributes to be added to the HTTP header. The specification is
# of the format response_attribute_name|http_header_name[,...].
# response_attribute_name is the attribute in policy response to be fetched and
# http_header_name is the name of the header to which the value needs to be
# assigned.
# NOTE: In most cases, in a destination application where a "http_header_name"
# shows up as a request header, it will be prefixed by HTTP_, and all
# lower case letters will become upper case, and any - will become _;
# For example, "common-name" would become "HTTP_COMMON_NAME"
com.sun.am.policy.agents.config.response.attribute.map=
# The cookie name used in iAS for sticky load balancing
com.sun.am.policy.am.lb.cookie.name = GX_jst
# indicate where a load balancer is used for Access Manager
# services.
# true | false
com.sun.am.load_balancer.enable = false
####Agent Configuration####
# this is for product versioning, please do not modify it
com.sun.am.policy.agents.config.version=2.2
# Set the url access logging level. the choices are
# LOG_NONE - do not log user access to url
# LOG_DENY - log url access that was denied.
# LOG_ALLOW - log url access that was allowed.
# LOG_BOTH - log url access that was allowed or denied.
com.sun.am.policy.agents.config.audit.accesstype = LOG_DENY
# Agent prefix
com.sun.am.policy.agents.config.agenturi.prefix = http://Dominoad.yjy.dqyt.petrochina:80/amagent
# Locale setting.
com.sun.am.policy.agents.config.locale = en_US
# The unique identifier for this agent instance.
com.sun.am.policy.agents.config.instance.name = unused
# Do SSO only
# Boolean attribute to indicate whether the agent will just enforce user
# authentication (SSO) without enforcing policies (authorization)
com.sun.am.policy.agents.config.do_sso_only = true
# The URL of the access denied page. If no value is specified, then
# the agent will return an HTTP status of 403 (Forbidden).
com.sun.am.policy.agents.config.accessdenied.url =
# This property indicates if FQDN checking is enabled or not.
com.sun.am.policy.agents.config.fqdn.check.enable = true
# Default FQDN is the fully qualified hostname that the users should use
# in order to access resources on this web server instance. This is a
# required configuration value without which the Web server may not
# startup correctly.
# The primary purpose of specifying this property is to ensure that if
# the users try to access protected resources on this web server
# instance without specifying the FQDN in the browser URL, the Agent
# can take corrective action and redirect the user to the URL that
# contains the correct FQDN.
# This property is set during the agent installation and need not be
# modified unless absolutely necessary to accommodate deployment
# requirements.
# WARNING: Invalid value for this property can result in the Web Server
# becoming unusable or the resources becoming inaccessible.
# See also: com.sun.am.policy.agents.config.fqdn.check.enable,
# com.sun.am.policy.agents.config.fqdn.map
com.sun.am.policy.agents.config.fqdn.default = Dominoad.yjy.dqyt.petrochina
# The FQDN Map is a simple map that enables the Agent to take corrective
# action in the case where the users may have typed in an incorrect URL
# such as by specifying partial hostname or using an IP address to
# access protected resources. It redirects the browser to the URL
# with fully qualified domain name so that cookies related to the domain
# are received by the agents.
# The format for this property is:
# com.sun.am.policy.agents.config.fqdn.map = [invalid_hostname|valid_hostname][,...]
# This property can also be used so that the agents use the name specified
# in this map instead of the web server's actual name. This can be
# accomplished by doing the following.
# Say you want your server to be addressed as xyz.hostname.com whereas the
# actual name of the server is abc.hostname.com. The browsers only knows
# xyz.hostname.com and you have specified polices using xyz.hostname.com at
# the Access Manager policy console, in this file set the mapping as
# com.sun.am.policy.agents.fqdn.map = valid|xyz.hostname.com
# Another example is if you have multiple virtual servers say rst.hostname.com,
# uvw.hostname.com and xyz.hostname.com pointing to the same actual server
# abc.hostname.com and each of the virtual servers have their own policies
# defined, then the fqdnMap should be defined as follows:
# com.sun.am.policy.agents.fqdn.map = valid1|rst.hostname.com,valid2|uvw.hostname.com,valid3|xyz.hostname.com
# WARNING: Invalid value for this property can result in the Web Server
# becoming unusable or the resources becoming inaccessible.
com.sun.am.policy.agents.config.fqdn.map =
# Cookie Reset
# This property must be set to true, if this agent needs to
# reset cookies in the response before redirecting to
# Access Manager for Authentication.
# By default this is set to false.
# Example : com.sun.am.policy.agents.config.cookie.reset.enable=true
com.sun.am.policy.agents.config.cookie.reset.enable=false
# This property gives the comma separated list of Cookies, that
# need to be included in the Redirect Response to Access Manager.
# This property is used only if the Cookie Reset feature is enabled.
# The Cookie details need to be specified in the following Format
# name[=value][;Domain=value]
# If "Domain" is not specified, then the default agent domain is
# used to set the Cookie.
# Example : com.sun.am.policy.agents.config.cookie.reset.list=LtpaToken,
# token=value;Domain=subdomain.domain.com
com.sun.am.policy.agents.config.cookie.reset.list=
# This property gives the space separated list of domains in
# which cookies have to be set in a CDSSO scenario. This property
# is used only if CDSSO is enabled.
# If this property is left blank then the fully qualified cookie
# domain for the agent server will be used for setting the cookie
# domain. In such case it is a host cookie instead of a domain cookie.
# Example : com.sun.am.policy.agents.config.cookie.domain.list=.sun.com .iplanet.com
com.sun.am.policy.agents.config.cookie.domain.list=
# user id returned if accessing global allow page and not authenticated
com.sun.am.policy.agents.config.anonymous_user=anonymous
# Enable/Disable REMOTE_USER processing for anonymous users
# true | false
com.sun.am.policy.agents.config.anonymous_user.enable=false
# Not enforced list is the list of URLs for which no authentication is
# required. Wildcards can be used to define a pattern of URLs.
# The URLs specified may not contain any query parameters.
# Each service have their own not enforced list. The service name is suffixed
# after "# com.sun.am.policy.agents.notenforcedList." to specify a list
# for a particular service. SPACE is the separator between the URL.
com.sun.am.policy.agents.config.notenforced_list = http://dominoad.yjy.dqyt.petrochina/*.nsf http://dominoad.yjy.dqyt.petrochina/teamroom.nsf/TROutline.gif?
OpenImageResource http://dominoad.yjy.dqyt.petrochina/icons/*.gif
# Boolean attribute to indicate whether the above list is a not enforced list
# or an enforced list; When the value is true, the list means enforced list,
# or in other words, the whole web site is open/accessible without
# authentication except for those URLs in the list.
com.sun.am.policy.agents.config.notenforced_list.invert = false
# Not enforced client IP address list is a list of client IP addresses.
# No authentication and authorization are required for the requests coming
# from these client IP addresses. The IP address must be in the form of
# eg: 192.168.12.2 1.1.1.1
com.sun.am.policy.agents.config.notenforced_client_ip_list =
# Enable POST data preservation; By default it is set to false
com.sun.am.policy.agents.config.postdata.preserve.enable = false
# POST data preservation : POST cache entry lifetime in minutes,
# After the specified interval, the entry will be dropped
com.sun.am.policy.agents.config.postcache.entry.lifetime = 10
# Cross-Domain Single Sign On URL
# Is CDSSO enabled.
com.sun.am.policy.agents.config.cdsso.enable=false
# This is the URL the user will be redirected to for authentication
# in a CDSSO Scenario.
com.sun.am.policy.agents.config.cdcservlet.url =
# Enable/Disable client IP address validation. This validate
# will check if the subsequent browser requests come from the
# same ip address that the SSO token is initially issued against
com.sun.am.policy.agents.config.client_ip_validation.enable = false
# Below properties are used to define cookie prefix and cookie max age
com.sun.am.policy.agents.config.profile.attribute.cookie.prefix = HTTP_
com.sun.am.policy.agents.config.profile.attribute.cookie.maxage = 300
# Logout URL - application's Logout URL.
# This URL is not enforced by policy.
# if set, agent will intercept this URL and destroy the user's session,
# if any. The application's logout URL will be allowed whether or not
# the session destroy is successful.
com.sun.am.policy.agents.config.logout.url=
#http://sportal.yjy.dqyt.petrochina/amserver/UI/Logout
# Any cookies to be reset upon logout in the same format as cookie_reset_list
com.sun.am.policy.agents.config.logout.cookie.reset.list =
# By default, when a policy decision for a resource is needed,
# agent gets and caches the policy decision of the resource and
# all resource from the root of the resource down, from the Access Manager.
# For example, if the resource is http://host/a/b/c, the the root of the
# resource is http://host/. This is because more resources from the
# same path are likely to be accessed subsequently.
# However this may take a long time the first time if there
# are many many policies defined under the root resource.
# To have agent get and cache the policy decision for the resource only,
# set the following property to false.
com.sun.am.policy.am.fetch_from_root_resource = true
# Whether to get the client's hostname through DNS reverse lookup for use
# in policy evaluation.
# It is true by default, if the property does not exist or if it is
# any value other than false.
com.sun.am.policy.agents.config.get_client_host_name = false
# The following property is to enable native encoding of
# ldap header attributes forwarded by agents. If set to true
# agent will encode the ldap header value in the default
# encoding of OS locale. If set to false ldap header values
# will be encoded in UTF-8
com.sun.am.policy.agents.config.convert_mbyte.enable = false
#When the not enforced list or policy has a wildcard '*' character, agent
#strips the path info from the request URI and uses the resulting request
#URI to check against the not enforced list or policy instead of the entire
#request URI, in order to prevent someone from getting access to any URI by
#simply appending the matching pattern in the policy or not enforced list.
#For example, if the not enforced list has the value http://host/*.gif,
#stripping the path info from the request URI will prevent someone from
#getting access to http://host/index.html by using the URL http://host/index.html?hack.gif.
#However when a web server (for exmample apache) is configured to be a reverse
#proxy server for a J2EE application server, path info is interpreted in a different
#manner since it maps to a resource on the proxy instead of the app server.
#This prevents the not enforced list or policy from being applied to part of
#the URI below the app serverpath if there is a wildcard character. For example,
#if the not enforced list has value http://host/webapp/servcontext/* and the
#request URL is http://host/webapp/servcontext/example.jsp the path info
#is /servcontext/example.jsp and the resulting request URL with path info stripped
#is http://host/webapp, which will not match the not enforced list. By setting the
#following property to true, the path info will not be stripped from the request URL
#even if there is a wild character in the not enforced list or policy.
#Be aware though that if this is set to true there should be nothing following the
#wildcard character '*' in the not enforced list or policy, or the
#security loophole described above may occur.
com.sun.am.policy.agents.config.ignore_path_info = false
# Override the request url given by the web server with
# the protocol, host or port of the agent's uri specified in
# the com.sun.am.policy.agents.agenturiprefix property.
# These may be needed if the agent is sitting behind a ssl off-loader,
# load balancer, or proxy, and either the protocol (HTTP scheme),
# hostname, or port of the machine in front of agent which users go through
# is different from the agent's protocol, host or port.
com.sun.am.policy.agents.config.override_protocol =
com.sun.am.policy.agents.config.override_host =
com.sun.am.policy.agents.config.override_port =
# Override the notification url in the same way as other request urls.
# Set this to true if any one of the override properties above is true,
# and if the notification url is coming through the proxy or load balancer
# in the same way as other request url's.
com.sun.am.policy.agents.config.override_notification.url =
# The following property defines how long to wait in attempting
# to connect to an Access Manager AUTH server.
# The default value is 2 seconds. This value needs to be increased
# when receiving the error "unable to find active Access Manager Auth server"
com.sun.am.policy.agents.config.connection_timeout =
# Time in milliseconds the agent will wait to receive the
# response from Access Manager. After the timeout, the connection
# will be drop.
# A value of 0 means that the agent will wait until receiving the response.
# WARNING: Invalid value for this property can result in
# the resources becoming inaccessible.
com.sun.am.receive_timeout = 0
# The three following properties are for IIS6 agent only.
# The two first properties allow to set a username and password that will be
# used by the authentication filter to pass the Windows challenge when the Basic
# Authentication option is selected in Microsoft IIS 6.0. The authentication
# filter is named amiis6auth.dll and is located in
# Agent_installation_directory/iis6/bin. It must be installed manually on
# the web site ("ISAPI Filters" tab in the properties of the web site).
# It must also be uninstalled manually when unintalling the agent.
# The last property defines the full path for the authentication filter log file.
com.sun.am.policy.agents.config.iis6.basicAuthentication.username =
com.sun.am.policy.agents.config.iis6.basicAuthentication.password =
com.sun.am.policy.agents.config.iis6.basicAuthentication.logFile = c:/Sun/Access_Manager/Agents/2.2/debug/C__Lotus_Domino/amAuthFilter

Hi,
I installed opensso (so Sun Java(TM) System Access Manager 7.5) and the agent for Domino 6.5.4 and I have the message in logs "amAgent"
2007-07-11 18:40:16.119 Error 1708:3dbcf768 PolicyAgent: render_response(): Entered.
I have the box to identify but it doesnot connect me on my opensso server.
It still identify with Domino's server
Thanks for your response
Thomas

Error while building cube using Relational Access Manager - URGENT

When we try to build the Express Hybrid database using Relational Access Manager, We got the following error in the Windows NT Event log.
"[159] XCA Interface - Exception C0000005 occurred in the XTLLISTN:ClientThread() function in the XWCXCA.DLL module"
We are using Oracle Express 6.3.2 and Windows NT 4.0 Enterprise and Oracle 8.1.7
Kindly Help
Thanks & Regards
ashish

We are using Oracle Express 6.3.2 and Windows NT 4.0 Enterprise and Oracle 8.1.7
-------------------------------------------------------------------------------- Unfortunately your configuration is not officially certified. You will want to upgrade to Express 6.3.2.1 in order to run against Oracle 8.1.7.
Server Certifications for Windows NT 4.0:
Express 6.3.2 with Oracle EE 8.1.6
Express 6.3.2.1 with Oracle EE 8.1.7 & 9.0.1
Express 6.3.4 with Oracle EE 8.1.7 & 9.0.1

Not able to open Access Manager

Hi,
Not able to open Access Manager after shut down the machine and when its started after a long time ( 2-3 hours), Its giving the error " The page is not found" . After configuring the IIS policy agent in other machine i m not getting the browser what i got b4ly. I m getting "U r not authorized to view this page". Pls reply Very Urgent.

Thanks Karthik.
1. Was this always like this or the issue is seen recently ?
2. Did you try opening Config Manager from Start menu or it's native folder ?
3. What type of Admin Workstation ( AW ) is this, from where you are trying to run config mgr ? Distributor or client AW ?
4. The error indicates towards issue in receiving " Real-time feed ( RTF )" . I would try restarting the AW & see if it restores the RTF which is a process running on it.
5. Try pinging ( ping -t ) to Logger from AW to see if there are any network issues.
GP

Access Manager 7.1, Webserver 7.0 and Policy Agent 2.2 Logging behaviour

Similar Messages

Maybe you are looking for