AD FS Error:
Exception details: Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.UnknownAuthenticationTypePolicyException: MSIS3305: None of the AuthenticationContext class references specified in the SAMLP request is supported by the server.
An SP we are working with have changed their saml authentication request. Now it forces a custom authenticationmethod that AD FS does not know.
The SP is setup as a relying party trust in the AD FS.
I have tried any and all ways I can find to try and change this with a custom claims rule, but my conclusion is that you can't change the incoming request in that way. Am I correct?
In case you want to see the latest one of many attempts
c:[Type == "urn:oasis:names:tc:SAML:2.0:assertion", Value =~ "^(?i)Custome-Value$"] => issue(Type = "urn:oasis:names:tc:SAML:2.0:assertion", Value = "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"(don't care here just want something else for testing));
The current flow(with the error): go to their site -> redirect to ours -> Authenticate -> Samlresponse
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext -> nothing happens on their site.
So my question is, do I really have to implement a whole library/plugin just to "accept" this new
saml:AuthnContextClassRef value. And then somehow code it to go about everything normally. Because the authentication part works normally with the user inputting what is required.
Or do I have any other options regarding this? If not, would anyone be able to link me to a more trusty source regarding its development, (https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method) from MS is not confidence inducing due to their disclaimer.
The example that you can build here is for educational purposes only. These instructions are for the simplest, most minimal implementation possible to expose the required elements of the model. There is no authentication back end, error processing, or configuration data.