For a future implementation, you might wanna look over this friendly introduction to liberty/saml on xml.com. Liberty and SAML propose pretty much the kind of stuff you want to do, and are an open (OASIS) standard.
http://www.xml.com/pub/a/2005/01/12/saml2.html Rob. On Wed, 16 Feb 2005 10:54:58 +1100, Taryn East <[EMAIL PROTECTED]> wrote: > ok, reading this has made me suspect my knowledge of cookies is much less > complete than I had at first thought... > I'm just going to ask a whole bunch more questions and hopefully nut out > the answers... > > * Matthew Palmer <[EMAIL PROTECTED]> spake thus: > > There's lots of things that can be done with cookies: > > > > The bog-basic way -- have the channel partner set a cookie for your site > > containing info on them. Maybe base64 encode it to keep out the casual > > poker. > > this would be ok for the channel partners logging into our site, but > wouldn't clients of the channel partner have issues with the cookies > being for the channel-partner site? how would their site set a cookie > for our site such that someone logging into their site can then get > into ours? > > > The hyper-secure option -- Provide each of your channel partners with the > > public portion of an asymmetric key, with which they encrypt the contents of > > the cookie, typically a unique ID of some sort, of perhaps other useful > > info. Your site then decrypts the cookie with the private portion of the > > key, and (assuming everything matches) grants appropriate access. Use > > asymmetric rather than symmetric so that insecurity at the other sites won't > > screw *you* over, and use a different key pair for each channel partner so > > that you can prove which partner provided the referral. > > this seems to be a way of securing the above... which is nice, but > probably OTT given that I know how dodgy security is already on our > site... while I'm trying to persuade them to change this, I may not be > able to do it on this project (especially as I'm the "junior" programmer > and the "senior" programmer is much more into "it's just easier this > way"... but I'm not bitter ;)) > > anyway, as I can see, the above raises the same questions for me as the > previous one - I'm not sure how we can then get this onto the > channel-partner's clients without having to hand each of them the key... > and I get the feeling this is similar to just handing them the login > details. > > To clarify, I think the business perspective here is that the channel > partners don't want their clients realising that they can just come to > our site by themselves without having to use the CP sites... they don't > want the middlemen (ie themselves) cut out :) So they don't want the > clients knowing that there is any other login even involved. > > > The WS option -- Have the channel partner generate a unique ID and send it > > to your site via some sort of basic SOAP interface, and hand the same ID (or > > derivative) to the user in a cookie set for your site. > > this sounds interesting and probably the better option in the long run - > but this also sounds like we would have to alter how we currently do > logins (currently via http authentication rather than SOAP options) > which is unlikely to be scoped into the current project. :( > > It's probably a good idea for our "next generation project", though. I > hear they're planning on changing over to "form based authentication"... > which to me means nothing and I haven't heard anything more about it > apart from just that, even after asking (I think I got some vague waffle > about it being "just better"). > > > Alternately, the channel partners could have individual portal pages which > > they point their users to, which you then set cookies or whatever to > > identify the visitor and they get redirected to the right place. > > by individual do you mean a different page for each user? Probably not a > good idea - I think they like their generic pages and I can understand > why. Otherwise I think I'm just confused... > > > > ok, now they aparrently used to do this by having a url with the > > > username/password in it (ie using "basic" http authentication with the > > > login details as parameters). > > > > Eeeeeeew. Why bother even *having* logins if they're going to send them to > > anyone that asks for them? > > yep, that's my reaction... again, I'm just a junior - what would I know > ;) > > I guess they like the impression of being secure without actually > putting all that "hard work and effort" that it'd obviously take to fix > it (not). <sigh> > > But then, this is business for you and I am just not surprised anymore. > > > > > There is a hell of a lot on the web on autologin functions from the > > > recipient side fo things (ie the one receiving the login details) but we > > > need some code to hand to our channel partners that can run on their > > > server to send the login details to us... something that can be > > > > Details of the partners' sites? If you're going to write it for them, > > unless they're all using the same environment and roughly the same websites, > > you're not going to be able to send them a one-size-fits-all bit of code. > > yes I know and I have informed my manager of this - he didn't realise it > and hoped that it could all be done at our end... he was hoping we could > just hand them a URL-solution like it was before... > > Anyway, I've convinced him that we can only offer possible solutions - > and he has asked me to write a demo area that we can show to CPs. The > PHP solution of CURL ofered in another thread sounds like a good one > because a lot of people can easily run PHP. A cookie solution would be > nice too as that is doable on pretty much all systems. Proprietary > solutions are less useful because we have no way of convincing people to > change over to such systems... and I wouldn't want to either. > > anyway, thanks for your help so far :) > Taryn > > -- > This .sig temporarily out-of-order. > We apologise for any inconvenience > - The Management > -- > SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ > Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html > -- Rob Sharp e: [EMAIL PROTECTED] w: quannum.co.uk j: [EMAIL PROTECTED] -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
