Привет всем.

Думаю, интерес к сборке System.Runtime.Remoting проявляют, если не все, то большинство. Я хочу обсудить ее минусы и предложить сообща доделать то, про что в Майкрософт то ли не додумались, то ли, преследуя корпоративные интересы, принципиально вычеркнули.
Речь пойдет о протоколах, помогающих пользователям использовать возможности сетевой безопасности без использования в них продуктов Майкрософт. В их числе SSL, SOCKS5, всевозможные виды аутентификации и прочее.

Для начала, следует указать, что именно Майкрософт сделала не так. А не по уму сделана всего одна вещь - отсутствует возможность расширения канала на транспортном уровне. Вероятно, это попытка продвижения на рынок сервера IIS... или просто просчет аналитиков, но вещь такая очень нужна. Без нее людям каждый раз приходится полностью переписывать классы XXXServerChannel.

И так. Что же предлагается сделать, что бы исправить эту досадную оплошность? Я предлагаю переписать канал с целью добавления в него возможности расширения и написать недостающие компоненты, такие как SslServerChannelSink и другие, какие вы предложите.

Далее речь пойдет пока только о серверном канале, хотя с клиентским те же проблемы.

Как предлагается организовать расширяемость?

Насколько известно, канал работает следующим образом (поправьте, если я где не прав):

1. Инициализируются параметры канала
2. Инициализируется цепочка канальных приемников
3. Запускается поток со слушающим сокетом
4. После установки нового соединения создается поток, читающий входные данные и отдающие его процедуре ProcessMessage первого канального приемника и далее по цепочке.

Предлагаю:
1. Добавить интерфейс IServerChannelExender, позволяющий расширять транспортный уровень настолько, насколько желает программист:

2. Вместо непонятных каналов HttpServerChannel и TcpServerChannel (непонятных потому что нет смысла в двух отдельных каналах - достаточно только одного общего ServerChannel и пары приемников HttpServerChannelSink и TcpServerChannelSink) создать три класса ServerChannel, HttpServerChannelSink, TcpServerChannelSink и провайдеров к последним двум.

3. В классе ServerChannel реализовать просмотр цепочки провайдеров, на предмет поиска в ней унаследованных от IServerChannelExtender и имеющих свойство WantToListen установленное в true и последующей передаче ему управления слушающим сокетом.

4. Написать HttpServerChannelSink и TcpServerChannelSink.

5. Написать другие xxxSink (например, SocksServerChannelSink)

Что мы получим в результате? В резальтате мы получим возможность конфигурации, дающей полный контроль над процессом:

<application>
<service>
<wellknown type="ServerType, Test" objectUri="ServerType.rem" mode="Singleton" />
</service>
<channels>

<channel ref="https" >
<serverProviders>
<provider ref="SocksServerChannelSinkProvider" socksAddress="proxy.domain.ru:1080" mode="socks5" />
<provider ref="SslServerChannelSinkProvider" certificate="certificate.cer" />
<provider ref="HttpServerChannelSinkProvider" />
<provider ref="AuthServerChannelSinkProvider" mode="Windows" >
<identity impersonate="true" />
</provider>
<provider ref="wsdl" />
<formatter ref="soap" />
<formatter ref="binary" />
</serverProviders>
</channel>
</channels>
</application>

Кому интересно - дальше писать?

Привет, человек с большой головой! :-)

BigheadmanА чем не устраивают варианты?
1) IIS: SSL, аутентификация
Я лично ничего против него собственно и не имею, но огород городить и для того, что бы использовать SSL поставить себе дыру под названием IIS... ну-ну..
Bigheadman
2) свое хост-приложение + tcp/http поверх IPSEC либо VPN

Это к чему? Ты предлагаешь, что бы каждый клиент создаваемого тобой приложения ходил к тебе через VPN?
Bigheadman
Если есть реальный коммерческий заказчик, то он скорее выберет один из предложенных вариантов, чем самописная безопасность. (Проверено!) Т.к. что вы там напишите - вопрос, а технологии из п.1-2 - native.
Про VPN я и спорить не стану, но применение его имеет очень узкую направленность. А насчет что лучше - самописная безопасность, имхо, гораздо лучше покупной, так как неизвестно еще что там в этих коммерческих сборках. Может, закладка на закладке? (Проверено!) :-) Т.к. что там за п.1-2 native, но не имея возможности видеть исходный код невозможно говорить, что там и кем накарябано...
Bigheadman
К тому же грядет FW2.0, а потом Indigo. Почитайте в обзорах, что там предлагается для решения этих задач.
А вот с этого места можно поподробнее? Что грядет? В FW2.0 я нового ни чего по теме не увидел кроме очередной темной лошадки по имени IpcChannel.
Что такое Indigo?
Bigheadman
P.S. Кстати http://www.genuinechannels.com]

Ты ценник видел? За десяток классов платить сто баксов! Каждому!!
Да, плюс тут вспоминается сразу про самописную безопасность... Dmitry Belikov не сам ее писал, что ли? Тестеров у него очень много было, что бы глюки проверить или он исходники в ФАПСИ сдавал и сертификат имеет? Чем он лучше сообщества людей, желающих дописать кусок фреймворка под свои нужды и предоставить другим людям полный исходный код?
Bigheadman
P.P.S. Не стоит изобретать велосипед, если в этом нет реальной необходимости.Ну фик знает, так можно вообще ни чего не делать, а сидеть и ждать, пока тебе все разжеванное на тарелочке принесут.

Один Indigo

Спасибо конечно, но вопрос был риторическим :-))

BigheadmanIIS для реализация SSL - не огород, а штатное средство, которое рекомендует MS. Если уж говорить "поставить себе дыру", то Windows - тоже "дыра".
Но поставленная за грамотным файрволом на unix/cisco из разряда дыр сразу выходит, что нельзя сказать об IIS.
BigheadmanIPSEC - можно шифровать трафик только по выбранному протоколу (порту).
VPN - что вы понимаете под узкой направленностью? VPN - одно из штатных средств организации защищенных сетей поверх незащищенных каналов.
Единственное, что я не учел - использование remoting-компонент в интернете для "публичного" использования. Здесь VPN и IPSec в общем случае неприменимы.О чем я уже говорил - узконаправленность.
BigheadmanПо поводу ФАПСИ и т.п. А вы свою реализацию тоже им на сертификацию отдадите????Лично знаю людей, которые это уже проходили. Если надо будет, то отдам. По мне дак открытость исходного кода и его широкое распространение и своевременная реакция на замечания людей, просмотревших его - уже залог того, что уровень безопасности на высоте.
Bigheadman genuinechannels [skip] И для коммерческих проектов вполне можно посмотреть в его сторону. Ну, да, конечно. Если денег много, а безопасность не имеет существенного значения.
BigheadmanЯ лишь хочу сказать, что нужно в каждой конкретной задаче четко определить требования и цели, чтобы затем выбрать соотв. средства их достижения.
Хотя если вам хочется реализовать такой проект, чтобы было, чтобы "дописать кусок фреймворка под свои нужды и предоставить другим людям полный исходный код", то дерзайте конечно.Будем считать что это и является целью :-))
BigheadmanЯ лишь привел свои аргументы, исходя из своего опыта реализации крупных коммерческих проектов.
Спасибо, я приму Ваше мнение во внимание.
BigheadmanP.S. Кстати у MS в мсдн в прошлом году была статья по поводу реализации защищенных каналов для remoting. Поищите. Хотя там всего лишь симметричное шифрование траффика + обмен ключами на стадии установления соединения.Читал. Вещь в себе. Не совместима ни с чем :-) ИМХО: заказная статья майкрософта по поводу отмазки на вопросы разгневанных пользователей.