<HTML dir=ltr><HEAD></HEAD>
<BODY style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV id=idOWAReplyText79552 dir=ltr>
<DIV dir=ltr><BR class=webkit-block-placeholder> </DIV></DIV>
<DIV>
<DIV>
<DIV>After you set your clock correctly, it looks from the IdP side like things are okay. Is there another problem you're encountering that I could help with?</DIV>
<DIV> </DIV></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV>Ill post some properly organized (and more concise!) technical details on the right list - so others attempting the same on win2008 Server can repeat the deployement from actual trial data or just counsel me based on their trials. But, in summary I did get the IDP to send an assertion. It took me 2 session of 2h and 2h of config file fiddling incrementally to find the valid set of values. But, things went fast at the end - once I obtained critical mass mastery of meaning of each element in the config file - and I got the various local log file settings to reveal the PDUs and/or transactional errors (e.g. date/time setting). This is all good time investement I feel, as it gave me an orientation on all the advanced features of Shib2 that go beyond today's openid profile - single logout, attribute querying, LDAP attribute profiling, ECP, backchannel assertion collection, etc. I have to recall that OpeniD2 may be wonderful - but its only one course in the feast.</DIV>
<DIV> </DIV>
<DIV>To be fair to Shib on the time outlay, I was learning a new Shell-based management system for the Windows IIS engine at the same time. It took me first time 30m just to a self-signed SSL server cert, too. It had also taken about 10minutes just to find out how to create an https endpoint and then bind a cert, too!</DIV>
<DIV> </DIV>
<DIV>The end state of affairs on the trial is ..I just cannot now "fully" consume the assertion using Shib2 on Win2008Server enterprise edition, due to "naming conflicts". But hours of trial and error copying of fields from the TestShib generated config into the distributed config has produced an almost-ran - that obviously will run, given elimination of a final configuration bug or two for either IIS or Shib2.</DIV>
<DIV> </DIV>
<DIV>The only way I found to get the normal sp-initiated websso flow actually invoked was to specifically use the "wong" domain-name for the Host/IIS configuration - otherwise the browser gets improper access to the secured resources without the SSO authentication flow being invoked. (i.e. the Shib filter in IIS's event pipline is deciding - based on the Shib SP config apparently and imemdiately when simply using the TestShib SP configuration per the instructions - not to involve itself when the host's actual domain name is used.). It then took further 2 steps of guessing to get to a reasonable finale. 1. Using both the incorrect host/IIS domain name AND an improper relying party SAMLentity name caused the IDP to reject the attempt to federate, quite properly. 2. Using then the correct relying party entity name did cause the IDP to generate and release more interesting errors/assertions (Hurrah!). Then I read the server logs, determining the needs to fix the RP time.</DIV>
<DIV> </DIV>
<DIV>It took about 10 minutes to learn to now setup up Windows time sync (an interesting diversion in and of itself). However, once time was righted, in the "websso flows do happen" cases the RP does now receive a positive assertion -- but it obviously comes back targetting the "wrong" IIS/Host entity. Shib2's RP logic properly rejects the assertion during "handling" - on the grounds that the named entity (whilst being the intended recipient in the crypto and SAML signaling sense) is not intended for the (improperly named) IIS/host binding. </DIV>
<DIV> </DIV>
<DIV>In conclusion, Im bascially deadlocked, now. If I enumerate what I know, then 1. I dont know if the RPs rejection of the happens before or after performing assertion decryption; 2 I do know that the encrypted assertion was a suprisingly large data blob; and 3. I do have a conjecture/rule - that the only configuration I could find to get the IDP to actually assert is teh very one that (properly) ensures that the SP cannot "handle" the result.</DIV></BLOCKQUOTE>
<BLOCKQUOTE type="cite">
<DIV id=idOWAReplyText54069 dir=ltr>There are 2 further goals - once interworking of Shib to Shib is accomplished. In preparation, I will of couse bolt the OpeniD gateway on the front, much as JanRain bolted openid on the front of CardSpace and SSL client auth. By the end of next week, this apparatus may allow me to (a) have openid-consumer-initiated websso to plaxo leverage the TestShib IDP once the OP decides to redirect to TestShib as an authentication provider, and (b) then induce a session on plaxo via true end-end sp-initiated websso - which leverages a custom/experimental openid consumer to translate the requests and assertions on the fly. </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>With any luck, given its RSA week, I'll then find someone to set the next goals. I want to make a playful chain of 5 handoffs next week: Cardspace -> TestShib -> openid -> SAML2-IDP-initiated -> Google Apps. Im also just dying also to play with a new Cisco SSLVPN unit, that will now assert SAML1.1 to such as chain - creating a SSLVPN tunnel to my customer's PCs networking stack. This will make me much happier on the neglected auth side of the study - getting me back to integrating with RSA's radius server ... to do the full SecurID OTP and pin handling protocol BEFORE applying the right websso handoff for the RP in question.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr> </DIV></BLOCKQUOTE></DIV></BODY></HTML>