[OpenID] FW: ProtectNetwork ID Activation Successful!

[Nate Klingenstein]

Peter,

> 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.
Great, thanks.  We're constantly seeking feedback from deployers so  
we can improve the defaults, packaging, and documentation.

> 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.
That's not too bad, given everything you had to learn.  It's just not  
possible to reduce the barrier below a certain level without making  
it too easy for deployers to harm themselves inadvertently.  This is  
software protecting and using sensitive information, after all, and a  
false sense of security is worse than knowing your kimono's open.

We're trying to "tier" the installation process as much as possible  
so that it's relatively easy to get the software running, but the  
path towards production is clear.  It's surprisingly difficult to do.

>  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!
The implementation relies heavily on information provided from the  
web environment, and some degree of familiarity with your server is a  
huge help for the deployment of Shibboleth.  It sounds like the vast  
majority of your problems had to do with the configuration of hosts  
within IIS and their mapping, which is not a fun place to get stuck.

> 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.

#1: Probably before, but the obviously an encrypted assertion could  
never have been sent if your public key weren't possessed by the IdP.

#2: The TestShib IdP is configured to send a ton of attributes, which  
accounts for half the size at least, but the blob will never be that  
small due to the need to include keying material.  The use of a back- 
channel callback with TLS authentication to get attributes, closer to  
how OpenID and classical Shibboleth work, is considerably leaner.   
However, it's imprudent to assume that the client-facing certificate  
is the certificate used for federated identity, and people have  
serious problems opening a separate port with a different  
certificate, so this always caused us some difficulty in practice.   
It's a tradeoff.  There are a lot of ways to do this, and we think  
this default will be the best choice in most cases.

#3: That's a problem, but not an axiom.  I recommend you bludgeon IIS  
into submission.

>> 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.

This would be cool.  Similar "identity gymnastics" have been  
demonstrated in the past by the federated identity community,  
particularly by Bob Morgan.

>> 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.

It should be pretty trivial to setup a provider that supports  
multiple authentication methods simultaneously for both protocols,  
and it's part of Shibboleth 2.0's design.  I don't know nearly as  
much as I'd like about SecurID, but FWIW:

http://svn.middleware.georgetown.edu/view/java-jaas-securid/trunk/edu/ 
internet2/middleware/shibboleth/jaas/securid/?root=shib- 
extension&pathrev=17

Take care,
Nate.