I have a custom Azure AD B2C Sign Up Invitation flow with a single policy key. The key is used to sign the token that's contained in the invitation link email and is then validated at sign up time. The cert is expiring soon and I'm trying to figure out how to not impact users who've not accepted an invitation.
The id token that we generate is good for 1 month.
I have a key container (B2C_1A_IdTokenHintCert) that has the current key. The key container is referenced in my custom policy. I'd like to add the renewed cert to the same key container so that there are 2 keys in the on container and then swap out the cert on the web server that generates the link with the signed token.
I'd like for both old links that are signed with the current cert and new links generated with the new cert be valid during signup.
Is this possible?
You can only have one value per policy key id. However, you can upload your new certificate as a new policy key, then add an additional technical profile into your user journey that validates your token hint against the new policy key. Example: Step 1 tries to validate the token hint against policy key 1, if it's not successful, then try to validate the token hint against policy key 2. That way old links and new links can both be validated.
You can have more than one certificate inside a key container. The system will use both to determine if the invitation token is valid up until the cert itself expires.
Related
This artile: https://anoopt.medium.com/accessing-sharepoint-data-using-postman-sharepoint-rest-api-76b70630bcbf
Explains how to generate a client ID, secret and set permissions so an application (java in our case) can add documents to sharepoint (not as a user, as a service)
It uses two hidden admin pages to a) create a new application credential set, b) to assign permissions.
https://yourtenantname.sharepoint.com/_layouts/15/appregnew.aspx
https://yourtenantname.sharepoint.com/_layouts/15/appinv.aspx
Our secret has now expired.
How can we generate a new secret? The only options sharepoint seem to provide is to create a new app, which gives a new client ID, which we don't have the ability to update on the fly in our app.
You are correct that .../AppRegNew.aspx is used to create new app/clientID/secret and is by default valid for 1 year.
To create a new client secret for an existing clientID with custom expiration date use the steps specified here:
https://learn.microsoft.com/en-us/sharepoint/dev/sp-add-ins/replace-an-expiring-client-secret-in-a-sharepoint-add-in
When building a Conversational Action with the new Actions SDK or Action Builder, you can define a webhook to handle business logic. This webhook then receives fulfillment requests with the following headers, among others:
Google-Actions-API-Version: "3"
Google-Assistant-Signature: "eyJhbGciOiJSUzI1NiIsImtpZC..."
How should that signature be verified? It's a JWT claim, but the key ID with which it was signed does not exist in the GCP account linked with the Action, and is not mentioned in the new Actions SDK documentation or in the Node.js fulfillment library documentation.
The signature is a JSON Web Token, which is an encoded way of transmitting some assertions that have been signed in a verifiable way. There are libraries that will both decode and verify JWTs. The general steps (some of which you can cache or shortcut) are:
Decode the header to get the kid (key id) and the payload to get the iss (issuer) fields. You'll also want the nbf (not before) and exp (expiration) fields to verify this was set recently and the aud field to verify that it matches your Google Cloud project ID.
Based on the issuer, access the well known openid configuration. Since the issuer is "https://accounts.google.com" you can access this at "https://accounts.google.com/.well-known/openid-configuration"
From the configuration document, you want the jwks_uri field, which is the URL to get the current JWT certificates. For Google, this is probably "https://www.googleapis.com/oauth2/v3/certs"
The certificate document should contain an array of keys. You want a key with the kid that matches the kid from the JWT. Note that these keys change frequently, but as long as you're within the window of the nbf and exp fields from the signature header, the key should exist in the certificate document.
With all this, you can then verify the signature portion of the JWT.
I've not been able to find decent information in the docs for this. Here's to the internet :)
This is my current understanding:
The documented approach is to create a ContentKeyPolicy with JWT restriction and Media Services will expect the claim added to the token of urn:microsoft:azure:mediaservices:contentkeyidentifier=INJECTED CONTENT KEY ID HERE based on what content the locator URL is serving up.
This means I'd need a new content key for every SKU sold to secure access to the media. Is there a way to hook into this authorization logic to say "I want you to call this API to run my custom validation" where I could check the JWT user's purchased content? This way only one content policy is really needed and becomes manageable.
The custom scenario you described is exactly the reason for using unique content key identifiers.
The way the key delivery server works with JWT tokens is that the key delivery server first checks to see which content key ID is being used. It then checks to see if the token is properly signed with the primary verification key that was used for that locator. Then it validates any claims that were applied when the encryption policies were set.
I'd recommend tracking the primary verification key (if unique per locator), the locator itself, the content key ID, and any claims in your own database so that all of those values are readily accessible for any of your content.
When you use Open ID connect with Azure AD, the JWT issued token (id token) is signed with an asymmetric key. I saw the public key to verify that signature is available in the metadata file, https://login.microsoftonline.com/common/discovery/keys. However, I couldn't find any documentation about how those keys are generated. How can you change the keys that are available there or how can I specify a different key to sign the JWTs for my tenant ?
All sources and information suggests that this certificate roll over is done by Azure AD them self. Consumers are not able to do a manual roll over or put a certificate of their preference. This claim is supported by this answer. Also, please check this press release which mention a roll over happened in 2016
From your end you must be be ready to accept a rollover any time. Best practice is to fetch key information through discovery document. This is explained in the openid connect documentation
According to this piece of documentation, only way how to have your own signing key for your application, is custom claims mapping. Although description is very vague and instructions how to do it are scarce.
What happens when the signing certificate (used for signing jwt tokens) expires when using IdentityServer 3?
It's unclear to me and I can't find any documentation, other than that it's possible to get a warning that it has expired. (Ref. https://identityserver.github.io/Documentation/docsv2/configuration/events.html)
Is there any mechanism that stops the use of expired signing certs?
And what happens on the client side (client being the Web API that uses IdentityServer for authentication) when validating a token signed by an expired certificate? (For example if https://github.com/IdentityServer/IdentityServer3.AccessTokenValidation is used as a middleware.)
Well I've just tested this (on IdentityServer4) and it seems to continue to work happily with an expired signing certificate, here's my test cert's validity:
I'm able to login, get an ID token and an access token and then access an API with the access token. What IdentityServer does do however is to log a warning:
2017-07-13 12:15:54.871 +02:00 [Warning]
Certificate "CN=test_expired_signing_certificate" has expired on "13/07/2016 14:14:37"
This matches what the IdentityServer (3) docs say here:
IdentityServer raises a number of events at runtime, e.g:
snip...
Expired/invalid/no signing certificate
By default these events are forwarded to the configured log provider - a custom event service can process or forward them in any way suitable for the environment.
So this would be your way of detecting it when it's already too late. A better option is to rollover signing keys periodically and within the validity of the keys, this is the common approach which also allows for a compromised key to be revoked if necessary. See this issue where the process is discussed, basically IdentityServer can handle two keys:
[Middleware refreshes] the metadata document ... once a day.
The metadata doc can hold 2 keys - primary and secondary and the middleware will load and use both when present (JWTs have a key identifier that allows picking the right one).
When you start to rollover - set both keys and at some point swap primary and secondary.
Disclaimer: I never worked with IdentityServer3
The outside world doesn't know your certificate and therefore doesn't know it's expired. The outside world merely sees your public key at:
YourIdentityServer.com/.well-known/openid-configuration
or more accurately:
YourIdentityServer.com/.well-known/openid-configuration/jwks
You can play around with this: Create a new cert on startup (see https://gist.github.com/mykeels/408a26fb9411aff8fb7506f53c77c57a). Even if you set the TimeSpan to one minute, it will keep working.
But once you wait 1 minute and restart your IdentityServer your token from last sign in will be considered invalid, because it was created with the now outdated signing key. It is checked against the new public key and fails.
It seems to be recommended to periodically replace your cert with a new one, while also keeping the previous key around, see "signing key rollover":
https://docs.identityserver.io/en/dev/topics/crypto.html#signing-key-rollover