I found this documentation https://devblogs.microsoft.com/aspnet/announcing-an-easier-way-to-use-latest-certificates-from-key-vault/ and some other ARM references to add a Keyvault extension to the VMSS inorder to acheive certificate auto-rotation. But, when I try to do a deployment, the extension just times out without giving any useful error message. For this to work are there any constraints, like say, the Key vault and the VMSS need to be on the same resource group ?? Does anyone know what might be wrong with my template.
Here's my extension:
{
"name": "KeyVaultForWindows",
"location": "[variables('location')]",
"properties": { "publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForWindows", "typeHandlerVersion": "0.0",
"autoUpgradeMinorVersion": true,
"settings":
{
"secretsManagementSettings": {
"pollingIntervalInS": "60",
"requireInitialSync": true,
"certificateStoreName": "MY",
"certificateStoreLocation": "LocalMachine",
"observedCertificates": ["https:///secrets/"] }
}
}
}```
Related
I am updating an internally developed single-page app (Typescript/React) that uses OAuth2 from AD-FS 2016 to Azure AD v2. Things are complicated slightly by the fact that I (the developer) don't have direct access to the Azure console and am working on this with a (non-developer) sysadmin who does.
I have implemented PKCE and got the flow working; I can now obtain JWT access, ID and refresh tokens from the server and authenticate them via JWKS. So far so good.
Now, my apps to know a couple more things:
whether or not the user should be treated as an administrator. This is inferred from group memberships
the preferred username and first name/surname of the user
The first of these we dealt with by setting up a "role" and mapping it out to groups in the Azure console. We then added the role claim to the tokens. I can find this as a string array in "id_token". No problem.
I was confused for a while because I was looking for it in "access_token", but it's not a problem for my app to use "id_token" instead.
The second is the thing that is really giving us problems. No matter what we put into the "optional claims" dialog - we've added all these fields and more, for the ID token, they do not appear in it. Nothing we are doing seems to affect the actual tokens that come out at all.
I am beginning to think that I have missed something out with regards to obtaining the information. I am using the https://graph.microsoft.com/profile, https://graph.microsoft.com/email and https://graph.microsoft.com/user.read scopes and the administrator has authorized these on behalf of the app. The user is synced from our in-house active directory, which the AD-FS is running from as well, so I know that this information is in there. I tried messing with the resource parameter but this is deprecated in Azure AD v2 apparently.
I've read and re-read https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-optional-claims along with other online documentation, and the following passage confuses me and makes me think that the issue might be related to scopes:
Access tokens are always generated using the manifest of the resource, not the client. So in the request ...scope=https://graph.microsoft.com/user.read... the resource is the Microsoft Graph API. Thus, the access token is created using the Microsoft Graph API manifest, not the client's manifest. Changing the manifest for your application will never cause tokens for the Microsoft Graph API to look different. In order to validate that your accessToken changes are in effect, request a token for your application, not another app.
Or is that just the reason that I switched to using the id_token?
The optional_claims section of the configuration manifest looks like this:
"optionalClaims": {
"idToken": [
{
"name": "email",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "upn",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "family_name",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "given_name",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "preferred_username",
"source": null,
"essential": false,
"additionalProperties": []
}
],
"accessToken": [
{
"name": "email",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": []
},
{
"name": "preferred_username",
"source": null,
"essential": false,
"additionalProperties": []
}
],
"saml2Token": [
{
"name": "groups",
"source": null,
"essential": false,
"additionalProperties": []
}
]
},
But the resulting payload in the ID tag looks like this:
{
"aud": "redacted",
"iss": "https://login.microsoftonline.com/redacted/v2.0",
"iat": 1654770319,
"nbf": 1654770319,
"exp": 1654774219,
"email": "redacted",
"groups": [
"redacted",
"redacted",
"redacted",
"redacted"
],
"rh": "redacted",
"roles": [
"redacted"
],
"sub": "redacted",
"tid": "redacted",
"uti": "redacted",
"ver": "2.0"
}
Can anyone who has more experience of the platform help me understand what we are doing wrong here? Do we need to define custom scopes? Have we simply forgotten to turn an option on?
All help gratefully received! Thanks in advance...
I tried to reproduce the same in my environment and got below results:
I have implemented PKCE flow and got JWT access, ID and refresh tokens.
I added optional claims like below:
Go to Azure Portal -> Azure Active Directory -> App Registrations -> Your App -> Token Configuration
Please check the scopes you are using to get token.
When I gave only openid as scope, got response like below:
But when I gave scope as openid profile email user.read, got all optional claims successfully like below:
I created a project that returns an array. Looking at the swagger.json everything looks fine, importing this swagger.json . But when I download the API definition from the developer portal I see some objects like ...Array, ...Array-1, ...Array-2. Which I don't expect:
How can I prevent this? How can I ensure that the generation behaves the same as my normal object (so no dashes, but dots). I created an example project that reproduces my issue: https://github.com/mvdiemen/SwaggerArrayGenerationExample.
Is this related to changes in Azure API management that are described over here? : https://blog.tomkerkhove.be/2018/04/13/changes-to-azure-api-management-openapi/
APIM does not support inlined schema. Try specifying schemas for response/request via $ref only, even if it's an array of object you've already defined - define a new object of type array and reference it.
So, instead of something like this:
"200": {
"description": "Success",
"schema": {
"uniqueItems": false,
"type": "array",
"items": {
"$ref": "#/definitions/SwaggerGenerationSample.Models.Response.Employee"
}
}
}
Have array itself defined in definitions and reference it:
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/EmployeeArray"
}
}
...
"definitions": {
"EmployeeArray": {
"uniqueItems": false,
"type": "array",
"items": {
"$ref": "#/definitions/SwaggerGenerationSample.Models.Response.Employee"
}
}
}
In Azure Active Directory I created an app, in the manifest file I've update the appRoles with the following value:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "Client manager",
"id": "bf77e391-0bbf-4e33-854b-a384a5ac0630",
"isEnabled": true,
"description": "Client manager can manage all client actions.",
"value": "ClientManager"
}]
I updated my user so that my assigned role is no longer Default Access but is Client manager
With Graph api I'm trying to retrieve this assigned role.
I tried this uri but for some reason it will not return my role(s).
https://graph.microsoft.com/beta/me/appRoleAssignments?$filter=resourceId eq 04dcaab1-7219-4689-8510-4672e957ac11$select=appRoleId
But the response is:
{
"error": {
"code": "BadRequest",
"message": "Invalid filter clause",
"innerError": {
"request-id": "ce3cb456-956b-41c5-84a2-cdcdfe1ac3c5",
"date": "2018-11-05T20:54:08"
}
}
}
I could create a workaround requesting all my roles, for all my applications but this is something I would like to avoid. This would end up with the following uri:
https://graph.microsoft.com/beta/me/appRoleAssignments?$select=resourceId,appRoleId
and results in this json, where I need to filter out my applicationid.
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#appRoleAssignments(resourceId,appRoleId)",
"value": [
{
"appRoleId": "00000000-0000-0000-0000-000000000000",
"resourceId": "667cc3aa-00b9-4526-bde5-b81312ed5afb"
},
{
"appRoleId": "00000000-0000-0000-0000-000000000000",
"resourceId": "64b92ac1-4a56-478c-8774-5c584fb200e5"
},
{
"appRoleId": "bf77e391-0bbf-4e33-854b-a384a5ac0630",
"resourceId": "04dcaab1-7219-4689-8510-4672e957ac11"
}
]
}
I tried several solutions proposed on StackOverflow already but for some reason, all the eq filters don't work. I'm testing my query with the Graph explorer. My desired result should be something like this:
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#appRoleAssignments(appRoleId)",
"value": [
{
"appRoleId": "bf77e391-0bbf-4e33-854b-a384a5ac0630"
}
]
}
It seems not support to filter resourceId with https://graph.microsoft.com/beta/me/appRoleAssignments.
As mentioned in the doc:
Not all parameters are supported across all Microsoft Graph APIs, and support might differ significantly between the v1.0 and beta endpoints.
Also, if we filter the id with GET https://graph.microsoft.com/beta/me/appRoleAssignments?$filter=id eq 'xxxxxxx', it will work fine. So I think the format of the query should be correct, the only possibility is it is not supported as mentioned in the doc.
I am trying to create schema extensions. I do have
"scp": "Directory.AccessAsUser.All" in token. Don't know for what reason it is failing.
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/schemaextension_post_schemaextensions
POST https://graph.microsoft.com/beta/schemaExtensions
Content-type: application/json
{
"id":"courses",
"description": "Graph Learn training courses extensions",
"targetTypes": [
"Group"
],
"properties": [
{
"name": "courseId",
"type": "Integer"
},
{
"name": "courseName",
"type": "String"
},
{
"name": "courseType",
"type": "String"
}
]
}
error :
{
"error": {
"code": "Service_InternalServerError",
"message": "Encountered an internal server error.",
"innerError": {
"request-id": "1909aef3-b66d-48de-8204-0a41df0a27a8",
"date": "2017-07-17T13:07:20"
}
}
}
Unfortunately it looks like Microsoft Graph schema extensions is not supported in B2C tenant (please confirm if you are NOT using a B2C tenant - in which case this might be a different problem).
In the meantime (until we fix this issue), you'll need to use Azure AD Graph to register and use directory extensions.
Hope this helps,
Can we use Rest API instead of using Lambda. The reason im asking is because we got the request, we know what alexa accepts as a response, and we know that it is a POST. So connect all of these into REST API. The reason im asking is that the whole project is based in Jax-RS, so we want to have it all in one place, wihtout using lamda or anything. Not that lamda isn't that great.
So the request that alexa passes to Lambda is:
{
"session": {
"sessionId": "SessionId.a82f0b92-3650-4d45-8f12-e030ffc10894",
"application": {
"applicationId": "amzn1.echo-sdk-ams.app.8f35038e-13ac-4327-8e4f-e5df52dc1432"
},
"attributes": {},
"user": {
"userId": "amzn1.ask.account.AFP3ZWPOS2BGJR7OWJZ3DHPKMOMNWY4AY66FUR7ILBWANIHQN73QGGUEQZ7YXOLC7NYVD3JPUAHAGUS4ZFXJ6ZMS4EHO2CJFPWFLWLYZLDP7S227ADI54A2ZMLZLDO5CXSIB47ELNY54S2M7FDNJFHTSU67B7HB3UZUN6OUUR5BYS3UBRSIPBG4IWRLHUN36NXDYBWUM3NMQZRA"
},
"new": true
},
"request": {
"type": "IntentRequest",
"requestId": "EdwRequestId.bfdb3c27-028b-4224-977a-558129808e9a",
"timestamp": "2016-07-11T17:52:55Z",
"intent": {
"name": "HelloWorldIntent",
"slots": {}
},
"locale": "en-US"
},
"version": "1.0"
}
Response:
{
"version": "1.0",
"response": {
"outputSpeech": {
"type": "PlainText",
"text": "Hello World!"
},
"card": {
"content": "Hello World!",
"title": "Greeter",
"type": "Simple"
},
"shouldEndSession": true
},
"sessionAttributes": {}
}
Sure you can. In fact, when you are creating your skill in the Alexa Developer Portal, you have that option. The caveat is that you will need to manage your own TLS certificate and will have to make sure that the latency/responsiveness is decent based on the location of your users.
If you would like to explore this further, you can use Amazon's Java code examples. They can be found at: https://github.com/amzn/alexa-skills-kit-java.
You can definitely set up a RESTful service API for use with Alexa.
And, if you set it up in Azure, you don't even need to create your own certificate.
You can use a rest api as the endpoint for alexa skills. The apis will be invoked in the following manner
[Configured_URL]>/**alexa/[intent]**
Where [Configured_URL] - is the url endpoint configured in amazon site for invoking
[intent] - is the name of the intent
You should host your service accordingly
https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/developing-an-alexa-skill-as-a-web-service
https://iwritecrappycode.wordpress.com/2016/04/01/create-an-alexa-skill-in-node-js-and-hosting-it-on-heroku/