Access denied in call

[erviem99]

Hi!

I'm trying to modify Digst.OioIdws.Rest.Example.Client to return an access token for thelookupservices described here, but I'm not having too much luck: https://cms.nemlog-in.dk/media/tb4l3i0i/nl3-supporting-services-v1-7.pdf

I modified the AsEndpoint (Access Token Issuer Endpoint) in the code to point to: https://lookupservice.test-devtest4-nemlog-in.dk/api/accesstoken/issue

I will get a saml-token back, but when I want to exchange that for an access-token I just get an "Access Denied" (Invalid token) back.

What is it that I am missing?

Regards,
Erik

[erviem99]

The integration tests also return either "SOAP signature recieved from STS does not validate!" or "Authentication failed".

Something is clearly wrong.

[martinwiboe]

@erviem99 did you get this to work? I can't even get STS to return a SAML token.

[erviem99]

Unfortunately not. It seems like it mostly broke around June 20, and is hasn't been working since.

I can see there is a service-window later this week and next week and I pin all my hopes on that now.

Communication from DIGST NemLog-in is almost non-existant (I've been trying for months now).

[martinwiboe]

This state of affairs is beyond sad -- NemLog-in is really a foundation of Danish public infrastructure.

I have replaced the client certificate with the one from https://www.nemlog-in.dk/vejledningertiltestmiljo/forside/test-som-tjenesteudbyder-eller-broker/ (in the Opslagstjenester section) and I have changed the AudienceUri accordingly to https://saml.wsp.lookupservice.test-devtest4-nemlog-in.dk. But I simply get a "Malformed request" error from STS.

I can see the request in the Log Viewer, but it fails with some exception on their end, and it's not clear why.
NemLog-in Support is not getting back to me.

Were you able to get a token from STS?

[erviem99]

I could not agree more.

It is also shocking that we are still using Ws-Trust protocol. Because of that we are stuck on the old .Net Framework.

I did the exact same thing as you without luck (and a million other combinations).

The only situation where I can get a SAML token back is by running the Digst.OioIdws.Rest.Examples.Client example.

Unfortunatly, I need the lookupservice just like you and not some test-service.

[martinwiboe]

Yes - once I get the sample to work, I will try to implement the WS-Trust request in .NET 6. Apparently parts of WCF are ported to the platform, but my first approach will be to construct the SOAP request manually. The code by ITfoxtec will serve as an inspiration in this regard.

I will update this thread if I make any progress.

[martinwiboe]

Also pinging @mdbech in case you have any input?

[erviem99]

I would love to see working code for Net6 that will also run under Linux. Please keep me posted :-)

[martinwiboe]

After running the code with the original certificate, but setting the AS endpoint to the one at test-devtest4, it looks to me as if the client is sending the EncryptedAssertion from STS directly to the AS. Won't this cause problems? I thought the encryption was done with the public key belonging to the client and thus unreadable for the AS.

[erviem99]

I don't think there is anything wrong with the code as I have had it working before with calls to lookupservice (in devtest4). It just stopped working around june 20, perhaps when the certificates was updated.

[erviem99]

@martinwiboe Any luck? Service Window is over but (of course) no information at all from Digst. It still does not work for me.

[martinwiboe]

I haven't had any luck. I received a response from NemLog-in Support, and I've asked them to look at this sample and why it's not working (rather than try to troubleshoot with my own certificate.) If they respond, I will update this thread.

I also believe that you are correct that there are no issues with the code. The STS response will be encrypted with the public key of the WSP (ie. the Authorization Service) and as such should not be decrypted by the consuming client.

Pinging @CBechmann

[erviem99]

I mangel på bedre tænkte jeg at vi måske kunne hjælpe hinanden lidt videre her...

Det er lykkes for mig at få et access-token tilbage fra STS ved at signere med et brugercertifikat udstedt herfra: https://erhvervsadministration.test-devtest4-nemlog-in.dk/. Man bestiller et nyt certifikat under punktet Brugercertifikat.

Der hvor jeg nå går fast er når jeg skal oprette en systembruger og tildele den privilegier til Lookup Service. Dette gøres under https://administration.devtest4-nemlog-in.dk/.

Jeg har gjort alt dette og fået en mail tilbage om at "Anmodningen er blevet godkendt", men desværre får jeg stadig en 403 (Forbidden) i kaldet til Lookup Service.

Der hvor kæden hopper af for mig er dog hvordan mit brugercertifikat kobles sammen med systembrugeren i Lookup Servicen. Det kan jeg ikke se nogen steder hvordan foregår.

Jeg ved selvfølgelig ikke om det er derfor jeg får en 403 tilbage...

[martinwiboe]

Det er en god idé. Jeg har modtaget svar fra NemLog-in support, men ikke noget brugbart -- jeg har bedt dem om at give anvisninger i at få sample til at virke.

Sker sammenkoblingen ikke via EntityId?

Det kan være, at jeg får tid til at prøve samme fremgangsmåde som dig i weekenden. Så vender jeg tilbage (og selvfølgelig også, hvis jeg kommer videre med supporten).

[erviem99]

Jeg er i tvivl, fordi EntityId indgår ikke i selve kaldet til Lookup Services (eks, api/lookup/ridcpr).

Der er dog en konfiguration på selve systembrugeren, hvor man skal indsætte et VOCES eller et FOCES certifikat og som benyttes til selve signeringen.

Jeg ved ikke helt hvor det certifikat skal komme fra, men hvis man har et IT-system sat op i administration.devtest4-nemlog-in.dk, så kan man downloade et signeringscertifikat (.cer - fil) fra siden for IT-systemet som fungerer.

Min udfordring er dog at jeg ikke har noget IT-system sat op til min nye testorganisation, og jeg ved ikke hvordan jeg gør dette.

Jeg satte derfor et andet certifikat ind som tilfældigvis havde liggende (fra en anden testorganisation), og det kan være derfor at jeg får en fejl nu.