Results 1 to 7 of 7

Thread: Beperken toegang class met code signing

  1. #1
    Registered User
    Join Date
    May 2006
    Location
    Overveen, vlakbij Haarlem, in Nederland.
    Posts
    11

    Question Beperken toegang class met code signing

    Ik heb het volgende geprobeerd en loop tegen problemen aan:
    1. genereer een nieuw keypair met 'sn -n keypair.dat'
    2. haal de public key eruit met 'sn -p public.snk'
    3. maak een tekstversie met 'sn -tp public.snk > public.txt'

    Ik heb nu keypair.dat (keypair file), public.snk (public key file) en public.txt waarin dit staat:
    Code:
    Microsoft (R) .NET Framework Strong Name Utility  Version 1.1.4322.573
    Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
    
    Public key is
    00240000048000009400000006020000002400005253413100040000010001001750f37c97de0a
    d8caca86e408a3cf7139d2d78a72ccb4c02a8d48d3c9739472b11e69e7c03564ff6245d69026e3
    96892cecc6abcae4df50a3186fedc9e5c49a791219571aaae31df2584088946879425b7d756796
    e33ba1b4e7d099e5f4756f1c54310804b09f3fc2653514693e0674d4ddc6b2bb694571377a1871
    1356d7b0
    
    Public key token is e11247b809200e1e
    Ik doe nu dit in Delphi 2005:
    1. bouw een nieuw package met een nieuwe unit
    2. in de unit definieer ik een interface IMyClass met als enig member een method Test
    3. bouw een nieuwe applicatie, die het package referenced, met een unit waarin TMyClass gedefinieerd wordt, met een werkende implementatie van Test


    De definitie van TMyClass:

    Code:
    [StrongNameIdentityPermissionAttribute
      (SecurityAction.LinkDemand,
      PublicKey=
        '00240000048000009400000006020000002400005253413100040000010001001750f37c97de0a'+
        'd8caca86e408a3cf7139d2d78a72ccb4c02a8d48d3c9739472b11e69e7c03564ff6245d69026e3'+
        '96892cecc6abcae4df50a3186fedc9e5c49a791219571aaae31df2584088946879425b7d756796'+
        'e33ba1b4e7d099e5f4756f1c54310804b09f3fc2653514693e0674d4ddc6b2bb694571377a1871'+
        '1356d7b0',
      Name='ClientApp',
      Version='1.0.0.0')]
    TMyClass = class (MarshalByRefObject, interfaces.IMyClass)
      private
      public
        procedure Test;
      end;
    Als ik e.e.a. goed begrijp beperk ik daarmee toegang tot de klasse tot toepassingen die 'ClientApp' heten, versie 1.0.0.0 en die signed zijn m.b.v. het keypair dat bij bovengenoemde public key hoort.

    Met remoting maak ik de klasse beschikbaar vanuit de server applicatie:
    Code:
    var
      aChannel: TcpServerChannel;
    begin
      aChannel := TcpServerChannel.Create(6601);
      ChannelServices.RegisterChannel(aChannel);
      RemotingConfiguration.RegisterWellKnownServiceType(
        TypeOf(TMyClass), 'myclass', WellKnownObjectMode.Singleton);
    end;
    Dan maak ik die client applicatie die erbij zou moeten kunnen:
    1. bouw een nieuwe applicatie ClientApp
    2. benader het object met remoting
    3. voer Test methode uit


    In de source van het project van de ClientApp staat:

    Code:
    [assembly: AssemblyTitle('ClientApp')]
    [assembly: AssemblyVersion('1.0.0.0')]
    [assembly: AssemblyKeyFile('keypair.snk')]
    Alles compileert prima, de server runt (met voor de zekerheid ook een vrijelijk beschikbare klasse die prima werkt), de client kan bij de server, maar dan krijg ik de volgende fout:

    Request for the permission of type System.Security.Permissions.StrongNameIdentityPerm ission, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
    Wat me opvalt is het versienummer en het niet kloppende PublicKeyToken, maar dat lijkt te slaan op mscorlib... Wat doe ik fout?

    Alvast bedankt voor het meedenken,
    JAAP.

  2. #2
    Registered User
    Join Date
    May 2006
    Location
    Overveen, vlakbij Haarlem, in Nederland.
    Posts
    11
    Als iemand een andere (degelijke) manier weet om in een .Net toepassing een klasse te beveiligen zodat niet iedereen met een IP- en poortnummer een klasse kan gebruiken, dan is dat ook welkom. Nu is het zo dat iedereen met IP-toegang tot mijn server ook toegang heeft tot deze server, ongeacht welke software daarbij gebruikt wordt en ongeacht het account waaronder ze ingelogd zijn. Als er een andere manier dan de hierboven beschreven manier is om dat te realiseren, hoor ik het graag...

    Groeten,
    JAAP.

  3. #3
    .NET remoting heeft volgens mij van zichzelf geen security. Is het een optie om het over HTTP (IIS) te draaien? Dan kun je gebruik maken van de security van IIS. Zo niet, dan zul je in je remoting server zelf de security moeten afvangen inderdaad. Dat noemt men dan: daar heb je de mogelijkheid je eigen security te maken.
    Marcel

  4. #4
    SillyMember
    Join Date
    May 2003
    Location
    Gent
    Posts
    7,725
    Voor LAN/WAN is IIS (en HTTP channel) ook de raad van Ingo Rammer.
    Lees ook de Non-Usage scenarios (webservices?).
    All methodologies are based on fear. -- Kent Beck.

  5. #5
    Registered User
    Join Date
    May 2006
    Location
    Overveen, vlakbij Haarlem, in Nederland.
    Posts
    11
    Tja, die optie had ik al overwogen, maar IIS is niet even een dll-tje wat je erbij gooit. Het is nogal een toepassing (zowel wat betreft resources als licentiekosten) om mee te moeten uitrollen voor de toepassing die me voor ogen staat. Niet onmogelijk, maar onwenselijk. Vandaar dat ik naar andere mogelijkheden voor authenticatie op zoek was, zelfs al zijn die minder sterk dat de ingebouwde (windows of anderzins) authenticatie van IIS.

    Om eerlijk te zijn lijkt het er een beetje op dat de hele .Net-security niet echt zonder IIS kan, wat me weer als een typische Microsoft streek voorkomt...

    Groeten,
    JAAP.

  6. #6
    SillyMember
    Join Date
    May 2003
    Location
    Gent
    Posts
    7,725
    In .NET 2.0 Remoting is in zowel HttpChannel als in TcpChannel voorzien in authentication en in encryption.
    In .NET 1.1 zal je het zelf moeten doen, bijvoorbeeld met Channel Sinks:
    All methodologies are based on fear. -- Kent Beck.

  7. #7
    Registered User
    Join Date
    May 2006
    Location
    Overveen, vlakbij Haarlem, in Nederland.
    Posts
    11
    Die oplossingsrichting had ik nog niet bekeken, dank voor de links.

    JAAP.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •