SAML Extension for WIF-IdP

Question

Anybody has any luck in creating IdP (STS) with newer SAML extension for WIF? I mean interactive IdP with Login page.

Thanks.

Answer 1

I've done this. Are you stuck? If so, on what?

---

Regards,

Travis Spencer
http://travisspencer.com

Answer 2

Ok, here is where I stand now...

The SSO endpoints in the sample are mapped to 

http://localhost:6010/IdentityProvider/saml/redirect/sso

but, there is no directory for /saml/... in IdP

1.My first question is how does Idp handles this request in absebse of folder? Is it done at SAML2AuthenticationModule?

2. Next, created an sample Login page and protected the site with FormsAuthentication. I changed the endpoint to a folder (say /secure) and protected it using location authorization. Thus forcing the IdP to a login page when request comes from SP. But the problem here is that controls goes to /secure folder after login happens and the SAML request is not processed.

It seems SSO request will be processed at SAML2AuthenticationModule level and returns back to Service Provider. If you force the request to app, you may trigger login interactivity, but looses the ability to process SAMLRequest.

Has anybody had any luck with this?

Answer 3

1.  It's a HttpModule -- specifically a Saml2AthenticationModule derived class.

On IIS 7 or 7.5, in integrated pipeline mode, HttpModules are loaded on all requests.

On IIS 6, you need to get a file with a type ASP.NET handles on the path like this:

http://example.com/fakeHandler.ashx/then/some/path/here

Depending on settings, you may have to actually create a fakeHandler.ashx file, but the path under it does not matter.  It needs to be a file, not a directory (else you may get a 404 in some configurations).  You can use this in your own pages, it'll be in Request.PathInfo.

 

2.  Response.RedirectToLoginPage always trashes HTTP forms, which is all SAML 2.0 P is. 

All the protocol is doing, under the cover, is a form post.

the RP outputs a page that has a 0 sec submit to your IDp.

Your IDp outputs a page with a 0 sec submit back to the RP.

 

What should get you working is turn auth off on your sign on endpoint.  Verify the request.  After you have verified the request, and only after you have verified the request, stash the forms collection into Session.  Redirect to your login page.  After login is finished, redirect to a new page.  On that page, regurgitate the saved request.  Post it back to your server.  This time, after you verify the request, you'll find that the user has already been authenticated -- and so you'll just continue execution.

On the plus side, this API is possible confirmation that Raymond Chen's time machine has been completed -- otherwise, clearly Microsoft has a freezer -- because this API could not possibly have been written in the past twenty years.

Answer 4

 

Thank you, Dave for your response.

I could not understand. Can you please explain further?