I am using Identity Server 4 to protect my APIs (Implicit Flow Mode) which are accessed by angular application. Every thing is working fine, however at specific period the access token suddenly became invalid even before its expiry.
Configuration:
Here is the Identity Server Startup file:
var identityBuilder = services.AddIdentityServer().AddInMemoryStores().SetTemporarySigningCredential();
identityBuilder.AddInMemoryScopes(identitySrvConfig.GetScopes());
identityBuilder.AddInMemoryClients(identitySrvConfig.GetClients());
Protecting the APIs:
app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
{
Authority = identityOptions.Authority,
ScopeName = "userProfile_api",
RequireHttpsMetadata = false
});
Investigation:
The issue was the bearer was not authenticated
Bearer was not authenticated. Failure message: IDX10501: Signature validation failed. Unable to match 'kid': 'e4f3534e5afd70ba74c245fe2e39c724', token
After some investigation, it appears that identity server is generating a new key which was causing the signature validation to fail.
In the log, I can see when the two warning events at end happening, then I see "Repository contains no viable default key" and "a new key should be added to the ring"
Questions
Why would there no be a key at anytime when the key lifetime is almost 3 months even I am using temporary signing (SetTemporarySigningCredential) and I am not restarting the server?
Creating key {a2fffa4a-345b-4f3b-bae7-454d567a1aee} with creation date 2017-03-03 19:15:28Z, activation date 2017-03-03 19:15:28Z, and expiration date 2017-06-01 19:15:28Z.
How can I solve this issue?
Creating a self signing certificate and removing the temporary signing on identity server fixed the issue.
var signingCertificate = new X509Certificate2("ReplaceByCertificatePath, "ReplaceByPasswordCertificate");
var identityBuilder = services.AddIdentityServer().AddInMemoryStores().SetSigningCredential(signingCertificate);
identityBuilder.AddInMemoryScopes(IdentitySrvConfig.GetScopes());
identityBuilder.AddInMemoryClients(IdentitySrvConfig.GetClients());
Related
So I was setting up an ADFS service on a Windows Server 2016 instance. I created a Relying Party Trust, and was about to create 2 claim issuance policies since our Service Provider has a nameId policy which needs to be met. The required policy is as follows
<NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress" AllowCreate="true"/>
So I added these two claims:
The second is a transformation rule as follows:
This resolves to the rule language:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
The problem is, that this generates a format of urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress and not urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress as in the requested policy and seemingly I can't change it to SAML2.0 as I can not manually edit the rule. Any ideas to fix this?
Copy that rule and use it to make a new custom policy rule and then edit it.
I am using Shibboleth SP for SAML authorization.
Recently IdP has changed the configuration and it now requires to sign the AuthRequest.
IdP's metadata has following parameter
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
WantAuthnRequestsSigned="true"><md:KeyDescriptor use="signing">
SP's shibboleth2.xml file had following tag
<ApplicationDefaults entityID="...."
REMOTE_USER="eppn persistent-id targeted-id email Email FirstName LastName NameID">
After IdP enforced AuthRequest signing, we changed our shibboleth2.xml file as following
<ApplicationDefaults entityID="..."
REMOTE_USER="eppn persistent-id targeted-id email
Email FirstName LastName NameID"
signing="true" encryption="true">
Basically, I added signing="true" and encryption="true".
After that the new Metadata generated has following attribute in tag
<md:SPSSODescriptor AuthnRequestsSigned="1"
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
Earlier AuthnRequestsSigned="1" attribute was not present.
After this when I try to authenticate, it gives us following error,
<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>
<samlp:StatusMessage>Unable to verify the signature</samlp:StatusMessage>
</samlp:Status>
Question 1: Do I need to give IdP this new metadata?
Question 2: Any idea why this is happening?
Question 3: Do I need to change anything else in the configuration?
P.S. Before enforcing AuthRequest signing, it was working, so I don't think there is any other issue in configuration.
Here is the sample AuthRequest which goes
<samlp:AuthnRequest
AssertionConsumerServiceURL="https://...SP-host.../Shibboleth.sso/SAML2/POST"
Destination="https://...idp-host.../marrsso/idp/SSO.saml2"
ID="...some-id..." IssueInstant="2019-01-11T14:13:25Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://...entity-id.../shibboleth</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>
I believe signing info should go here as part of request. As http request, it goes as GET request, is that correct?
When I see the request in network, I can see the Signature going as query param
The status code of the request is '200'
It is not unusual to send the signature as part of the query string. Its like a pre-signed URL.
Just enabling "signing=true" on SP should not change the key that
was originally generated. So re-sending the metadata is not a
requirement. Check with IdP if the SP's metadata was originally
imported in full or did they just add relying-party and other basic end
points to integrate, that might work just fine if request signing is
not required.
If IdP is not able to verify the signature then they must be missing
the certificate from SP. To be sure compare the two metadata files
before and after enabling signing and encryption, they should
match(specially around certificates) but for the additional attribute
that you had already identified. Resend the metadata otherwise.
No other configuration changes are required in this case.
[AspNet.Security.OpenIdConnect.Server] 2.0.0-rc2-final
Doubt about refresh token.
Is there any mechanism so that after updating a .net core project (DLLs), or with the application restart (IIS), a token can be revalidated so that the user remains valid and logged in?
today with each new update of my project, the token is invalidated and the user is disconnected from the application and a new login is required.
after an update the returned message is:
The specified refresh token is invalid.
thanks.
Are you using a developer certificate to sign the token? It seems that you don't use a fixed certificate. The certificate is used to encode and decode the token. If the certificate changes (on restart of the app) then all tokens become invalid.
To set a fixed signing certificate:
var cert = new X509Certificate2("TokenCertificate.pfx", "MySecret",
X509KeyStorageFlags.MachineKeySet |
X509KeyStorageFlags.PersistKeySet |
X509KeyStorageFlags.Exportable);
services
.AddAuthentication( ... )
.AddJwtBearer( ... )
.AddOpenIdConnectServer(options =>
{
options.SigningCredentials.AddCertificate(cert);
...
});
There
I'm using MicrosoftAzureMobile ios framework to connect to an azure mobile app with authentication enabled. I configured the service with facebook login. I can successfully login with FBSDKLogin as well as MicrosoftAzureMobile.MSClient.loginWithProvider with provider and controller. However when I try the loginwithProvider with token get from FBSDK,
let accessToken = FBSDKAccessToken.currentAccessToken()
client.loginWithProvider("facebook", token: ["access_token":accessToken]){
I got below error
MicrosoftAzureMobile.MSClient.loginWithProvider with provider and token failed with return Code=-1505 "The token provided was not valid.
how do I debug this issue? the azure portal's tools/streaming logs works last week but always shows connecting today
thanks
Joe
problem solved, i have to use accessToken.tokenString because accessToken itself is not serializable to json
Have called many restful services from asp before - but this one has me stumped.
First my func looks like
Set objHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP")
with objHTTP
.open "post", x_posturl, False
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
.send x_xmlstr
end with
and the error returned is
msxml3.dll error '80072f0d' The certificate authority is invalid or
incorrect
so, googled a bit and suggestion was to add line
.setOption 2, 13056
this gives error
msxml3.dll error '80072f0c' A certificate is required to complete
client authentication
I then contacted service supplier and they suggested
Click on the certificate error next to the address bar, view the
certificate, select Details, select Copy to File, and download it to a
file. Install that into your trusted certificates on your server to
stop the error appearing when trying to submit data.
So, tried that using instructions here - but still no joy, any help appreciated
It seems like the server located at x_posturl has a certificate that is misconfigured, or that your client computer doesn't contain/recognize the certificate's root authority (most likely). There are a few options to fix:
Have them fix their certificate if it's misconfigured.
If their certificate is valid, but with a root authority your machine doesn't recognize, then you need to install the root authority certificate locally.
Instruct MSXML2.ServerXMLHTTP to ignore certificate errors, which appears to be answered here: VBA ServerXMLHTTP https request with self signed certificate
Change x_posturl to start with http:// instead of https://— if it's supported by the provider. Would not recommend this in a production scenario though.
Can you share specifically what x_posturl is? We should be able to debug by looking at the SSL handshake.
I was able to find the solution by passing in a param.
objHTTP.SetOption 2, objHTTP.GetOption(2)
Dim objHTTP
Set objHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP")
objHTTP.SetOption 2, objHTTP.GetOption(2)
objHTTP.Open "post", x_posturl, False
objHTTP.SetRequestHeader "Content-Type", "application/x-www-form-urlencoded"
objHTTP.Send x_xmlstr