[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saml-dev] SAML and Siteminder question
Hi Nathan, I think that talking to the IT people again is the better approach. >From my experience with SiteMinder 5.5 and 6.0, you have the following options (some of the stuff below is more SiteMinder and less relevant to strictly SAML discussions): 1) As Darren said, if your university already has the Netegrity/eTrust Federated Web Services installed (part of the Policy Server Option Pack) and has configured it accordingly, you might be able to leverage it. If your university has a license for something called the SAML Affiliate Agent (this is a site license, so it shouldn't cost you anything), you can configure it as part of the solution to do the hard work and parse the SAML assertions for you. You then only need to pick up the HTTP headers containing the user entitlement information you need to authenticate people for your application. The problem here is that the affiliate and your application should really be on the same physical network so that you don't open up your site to potential security vulnerabilities through header spoofing. However, this is by far the easiest solution (providing the university has the license for the Affiliate Agent; the Option Pack/Federated Web Services (FWS) is freely available if you already have a policy server license). 2) Again, if the FWS is available, but not the affiliate, you can implement a SAML consumer as Darren mentioned. SiteMinder supports identity federation without using the affiliate agent, but you need to write the SAML consumer part. Both 1&2 require the same amount of configuration on the Policy Server side of things (the SiteMinder admin people are responsible for this work). I'm not quite sure which Netegrity agent you're talking about, but as for decrypting the cookie yourself, you'll still need an appropriate license (or good cracking skills). Netegrity provide both C and Java SDKs which can be used to decrypt the cookies and assert the identity however you want (this is how the application server agents work, for example), but something will have to bridge your ColdFusion and the C/Java code. Also, just to note that the encryption of the SMSESSION/SMIDENTITY cookies are based on rotating keys, so if you do manage to do it without Netegrity, you'll still have to manage to keep up with the key rotation. A final option, if you can somehow get your application hosted within their datacenter, is to allow the SiteMinder agent to build headers with the user's identity (providing this is all you need, anyway). You pick up the header in your app, and you're in business. SiteMinder traps all of the authentication requests normally--you don't have to do anything. However, this has the same potential security implications as the affiliate agent, and it requires customization of the SiteMinder policies by the SM administrators. If none of these options work, I'm not sure what else you can do except shell out the dosh. Hope this helps, ast On Fri, 2005-09-09 at 17:21, Nathan Given wrote: > If you are using siteminder the only way to decrypt their > cookie is either through their agent or some API call. > ColdFusion is a different web/app server and won't know how to > do anything with that cookie. Your application will always > present the user a login page unless your CF server has either > an agent or makes an API call to decrypt the cookie. I use a > 'similar product' and the cookie created by siteminder will be > decrypted by their proprietary decryption algorithm -- which I > don't think is available as open source. > > Okay, so, where can I read about making an API call to siteminder to > decrypt the cookie? If I can use java, I *should* be able to > integrate into coldfusion. > > Also, what is the 'similar product'? If it isn't too expensive, > perhaps I can make a case for purchasing it. > > Thanks! > -- > Nathan *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. ***************************************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]