Hello Ben, I looked at the Configuration Guide's list of the parameters related to area and notification and this is what i found: Option: External-Authentication-Return-Data-Capabilities Description: A bit mask that allows you to specify the return data capabilities for the current AREA plugin. This setting does not control the AREA plugin, it merely desecribes the behavior of the plugin, allowing for server optimization. Acceptable values are as follows: - Bit 1 (Value = 1) - no email address will be provided - Bit 2 (Value = 2) - no notify mechanism will be provided - Bit 3 (Value = 4) - no group identifiers will be provided - Bit 4 (Value = 8) - no license information will be provided. - Bit 5 (Value = 16) - no notification user validation should occur. The default is 0, meaning the server wil attempt to retrieve this information from AREA. A value of 7 will allow the server to potentially reduce the number of AREA related calls during notification processing. A value of 16 will allow the server to avoid using AREA for notification user validation and information retrieval. Use this setting for sites using a form of AREA that applies user names as email addresses and where there is no benefit to accessing an authentication database. So if I put the External-Authentication-Return-Data-Capabilities in the ar.cfg and set it to 16, will ARS stop calling AREA twice?
Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] ---------------------------------------------------------------------------- ------ Some people see things as they are and say... "Why?" I dream of things that never were and say... "Why not?" _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shanmugadas, Suresh Sent: Monday, January 29, 2007 2:28 PM To: [email protected] Subject: Re: SSO Problem: AREA being called more than once ** Hi Mikhail/Fellow Listers I am facing the exact same problem like yours today. but I am implementing AREA SSSO for the firsttime in 7.0.1. I am passing 2 secret passwords from Midtier. So when the Callback function in AREA is called , it validates these values and it is successful. but it gets called again for some reason and this time it is getting my windows login credentials in the parameters sent to AREA and it is failing. Our Env: ARS 7.0.1 Midtier 7.0.1 Win 2003 server IIS/TOMCAT IE <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Username: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> [EMAIL PROTECTED] <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Password: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Network Address: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Auth String: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA PASS_STRING: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA AUTH_STRING_DEFAULT: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User logging in from a matching Authentication String and Mid-Tier IP: <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User passed AREA SSO authentication. Login Success <PLGN> <TID: 000472> <RPC ID: 0000000001> <Queue: AREA > <Client-RPC: 390695> -VL OK <PLGN> <TID: 000472> <RPC ID: 0000000003> <Queue: AREA > <Client-RPC: 390695> +NS AREANeedToSyncCallback <PLGN> <TID: 000472> <RPC ID: 0000000003> <Queue: AREA > <Client-RPC: 390695> -NS OK -- 0 <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> +VL AREAVerifyLoginCallback -- user suresh.shanmugadas <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Username: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> suresh.shanmugadas <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Password: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO>xxxxxxxxxx <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Network Address: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> 10.XXX.XX.XXX <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> Auth String: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> @schwab.com <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA PASS_STRING: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> FIRSTPASS <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> From AREA AUTH_STRING_DEFAULT: <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> SECONDPASS <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User did not provide a valid Password String. <PLGN> <TID: 000472> <RPC ID: 0000000005> <Queue: AREA > <Client-RPC: 390695> <AREA.SURESH.CUSTOM.SSO> <INFO> User did not pass AREA SSO authentication. Login Failed Any suggestions/advice please. Thank you SK _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: Monday, January 29, 2007 8:36 AM To: [email protected] Subject: SSO Problem: AREA being called more than once ** Hi List, Has anyone ever had any problems with their AREA being called more than once? In the password field, a one-time-use token is being passed in. AREA then calls SSO with that token, then SSO verifies the validity of the token. However since the AREA code is being called more than once, the same token that was being validated the first time it went through, is being validated again, and so SSO of course will say no. The AREA code we are using now is exactly the same as our old AREA code in ARS 6.3, which worked (we upgraded to ARS 7.0). Does anyone have any thoughts on this? Please let me know. Thanks! Mikhail Serate Remedy Development Team Information Technologies University of Calgary (403) 210-9308 [EMAIL PROTECTED] ---------------------------------------------------------------------------- ------ Some people see things as they are and say... "Why?" I dream of things that never were and say... "Why not?" __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
