I had this issue and the reason for my AREA plugin getting called twice was because, the userid that was sent from Midtier was slightly different from what I would get without SSSO. ex. Normally, I would get it as username : suresh.shanmugadas but with the SSSO I was sending it as [EMAIL PROTECTED] and since I had AREA chaining and because SSSO was not able to Authenticate the user as [EMAIL PROTECTED] it was firing the LDAP authentication. That was the reason it was firing twice for me. HTH Suresh ________________________________
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, January 31, 2007 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** Add the bits together to implement multiple parameters. e.g., a value of 31 will disable all callbacks. Axton Grams On 1/31/07, Ben Chernys < [EMAIL PROTECTED]> wrote: ** First, I would code the AREA plug-in to handle all calls properly. You do not need to authenticate on the subsequent calls unless a timeout is reached. You will need to provide address info and an OK return code. Then, yes, 16 seems like it should work though the comments are confusing. Perhaps 7 is more correct. Note that you will have to restart the plug-in server to reload this value. Try it and see.... Ben ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mikhail Serate Sent: January 30, 2007 10:33 PM To: arslist@ARSLIST.ORG Subject: Re: SSO Problem: AREA being called more than once ** 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: arslist@ARSLIST.ORG 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: arslist@ARSLIST.ORG 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___ __20060125_______________________This posting was submitted with HTML in it___ __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"
