question

testuser7-8288 avatar image
0 Votes"
testuser7-8288 asked sikumars commented

azure ad key-credential

Hello,

As we know, we can add one or more passwordCredentials and keyCredentials in the application-object that we have registered in our Azure AD tenant.

My understanding is when the Service-principal object is created off of this application-object (once admin or user does the consent) , the SAME passwordCredentials and keyCredentials are added into the SP object

Above statement is TRUE even if this SP object is created in different tenant (assuming this was a multi-tenant app)
Meaning ,the SAME passwordCredentials and keyCredentials will accompany the SP created in consumer-tenant.

If I am correct then my question is,
what is the use-case to directly add passwordCredentials and keyCredentials into the Service-principal object ??
I personally feel that passwordCredentials and keyCredentials should be READ-ONLY property into the Service-principal object.


In which scenario it is necessary and will such credentials show up in the application-object ?

Thanks.


azure-active-directory
· 1
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

sikumars avatar image sikumars ·

@testuser7-8288,

Thank you for your time and sharing feedback on this thread which help us improving quality of the answer. I would like to check with you to see if there are further questions regarding this matter. If this answers your query, please don’t forget to click "Accept the answer" and Up-Vote for the same, which might be beneficial to other community members reading this thread. And, if you have any further query do let us know.

0 Votes 0 ·

1 Answer

amanpreetsingh-msft avatar image
0 Votes"
amanpreetsingh-msft answered amanpreetsingh-msft edited

Hi @testuser7-8288 • Thank you for reaching out.

The passwordCredentials and keyCredentials added to the application-object are not added to the corresponding servicePrincipal object. When users or administrators in the consumer tenants consent a Multi-tenant application, the servicePrincipal object gets created in their tenant without any passwordCredentials and keyCredentials, even when these credentials are set on the application object within the provider's tenant.

As an administrator of the consumer tenant, if you make the below graph call or run the equivalent PowerShell cmdlet to fetch the servicePrincipal details, you will only see an empty array for these attributes, regardless of whether the application object is configured with these credentials or not.

You will only see the password and key credentials on a servicePrincipal if those are explicitly set on the SP object using the addPassword method, as mentioned below:

 POST https://graph.microsoft.com/beta/servicePrincipals/{id}/addPassword
 Content-type: application/json
    
 {
   "passwordCredential": {
     "displayName": "Password friendly name"
   }
 }

Credentials are usually added to an SP object when there is no corresponding application object present in the same tenant and a token needs to be acquired in the context of the service principal using client_credentials flow. As this flow requires a certificate/secret to be passed in the request body for token acquisition, credentials must be added to the service principal.

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

· 6
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

testuser7-8288 avatar image testuser7-8288 ·

oh really !!! Thanks @amanpreetsingh-msft

So if passwordCredentials and keyCredentials of app-object are NOT added to the corresponding servicePrincipal object, then when app does Client-credential flow OR when web-app is exchanging the temp-auth-code with the token , it is important that this app's servicePrincipal object MUST be pre-populated with the credential.

The credential created during app-registration --> Certificates & secrets blade is of NO use because this creds will go in the app-object.

Am I correct ?

If I am, then how will above concept help creating a credential in servicePrincipal object of multi-tenant-app ??
I believe the "admin of app-developer tenant" can NOT access the consumer-tenant where the SP is dumped once the admin of consumer-tenant gives consent .
If app-developer does NOT know the credential, the app-code can not get the token from consumer-tenant .
or
before the FIRST consumer-tenant onboards the app in his tenant, the developer of the app MUST update the SP in his home-tenant with the credentials.


And secondly, what is the purpose of creating credentials in application-object either through portal or through addPassword() and addKey() on app-object ??

Thanks.

0 Votes 0 ·
amanpreetsingh-msft avatar image amanpreetsingh-msft testuser7-8288 ·

@testuser7-8288 • Service principal is required because it is the subject to which the token is issued. If you decode the Access Token that you acquire using client_credentials flow, you can see the sub claim contains the object ID of the servicePrincipal, NOT the object ID of the application.

The client_id parameter in the request body of the client_credentials flow is the application ID that is the same for both the Application object (under app registration) and the servicePrincipal object (under enterprise applications). If the servicePrincipal and Application objects are in the same tenant, password credentials (client_secret) can be verified under application object but if the SP is in a different tenant (in multi-tenant app scenario), the password credentials must be present in the servicePrincipal object.

Hope this covers answers to all your questions.

0 Votes 0 ·
testuser7-8288 avatar image testuser7-8288 ·

I understand that the sub claim contains the object ID of the servicePrincipal, NOT the object ID of the application in client_credentials flow.
And that is why you are saying that the credential should also come from the servicePrincipal object.


As you said, if the SP is in a different tenant (in multi-tenant app scenario), the password-credential must be present in the servicePrincipal object.
And that is want I wanted to practically visualize how it would play out.

So if I am app-developer and register one multi-tenant app in my home-tenant through portal, I know that SP will automatically created for me.
However, this app is NOT yet ready for consumer tenant to onboard.
Since portal does NOT have blade to add credential in SP, I have to use graph-api and addPassword() in SP object.

Now any other tenant can get this SP and now my app code can verify to this consumer tenant while getting token.


Am I correct ?

Thanks.



0 Votes 0 ·
amanpreetsingh-msft avatar image amanpreetsingh-msft testuser7-8288 ·

@testuser7-8288 • Yes, you are correct.

Just wanted to point out that addPassword() won't be required for all flows. For example, it will be required for client_credentials flow but not for Implicit flow. You can get a token without addPassword() using the below implicit call once the SP in the consumer tenant is created:

https://login.microsoftonline.com/consumer_tenant_id_or_name/oauth2/v2.0/authorize?client_id=your_sp_app_id&response_type=token&redirect_uri=https://jwt.ms&state=1234&scope=user.read



0 Votes 0 ·
testuser7-8288 avatar image testuser7-8288 ·

Oh yes, Implicit flow will NOT require password.
However, in my org we only prefer authorization-code-grant flow or client-credential flow.


Overall, it was good thing to know that that app-object and sp-object's credential sets are different.
Thanks @amanpreetsingh-msft Appreciate it.

0 Votes 0 ·
amanpreetsingh-msft avatar image amanpreetsingh-msft testuser7-8288 ·

@testuser7-8288 • Glad that you found the information helpful. Kindly "Accept the answer" and share your feedback as it will help us and others in the community.

0 Votes 0 ·