I have a site running RPS to authenticate users using personal Microsoft Live ID accounts. I am identifying them using the PUID right now.
I am now reworking the authentication of this site to use OIDC/OAuth, meaning that I won't get the PUID of my users anymore, but just the nameidentifier claim.
How is it possible for me to migrate users from RPS (PUID) to OIDC (nameidentifier)? Like querying the PUID using the nameidentifier?
I can't find any relevant information on PUID anymore, or RPS for that matter.
While this doesn't answer the exact question, after some testing I've found a workaround as follows:
The ID from MSA OAuth endpoint is the same as the one from Microsoft graph API.
This is actually the API used by many middlewares to get the User ID within Microsoft. It is called "id" in the /profiles/me endpoint.
This "id" is also called CID.
RPS can also retrieve a MSA CID, so it's basically working the other way around. It's not about mapping them by getting the PUID from OAuth, but getting the CID from RPS.
Related
I try to implement the microsoft auth into my application using Laravel Socialite, but since I'm working in a multi-tenant environment, I need to assign a user to a organisation. Is there anything such a microsoft organisation id or a domain name I can access in the docs? I'm unable to find it in the docs.
Also I try to get the street, postal and city and wasn't able to access that as well, but this is not as critical as the company identifier.
I found this thread, but it handles over Google, so maybe the approach might be similar:
How do I get a user's organization id when they login with Google oauth?
As I searched, I also found this docs, which seems to list all available fields of oauth: https://learn.microsoft.com/de-de/azure/active-directory/develop/id-tokens
https://learn.microsoft.com/en-us/graph/auth-v2-user#4-use-the-access-token-to-call-microsoft-graph
According to this docs: https://learn.microsoft.com/en-gb/previous-versions/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes you can add tenant details to the request including the id, display name and verified domains.
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I'm in throws of moving our security architecture from ASP.NET Core Identity to Azure AD V2 with MSAL.js. We used a lot of Roles with the ASP.NET Core Identity implementation and the information was managed in the database using the web application. The pattern I'm abandoning is similar to this one.
https://www.dotnetcurry.com/aspnet-core/role-based-security
Azure AD with MSAL is working. The tokens are being created and passed and the local Web API Endpoints decorated with the generic [Authorize] attribute are being honored as you would expect. Web API Endpoints decorated with [Authorize(Roles= "Fee, Foo, Fi, Fum")] are throwing a 401 unauthorized error.
I'm not sure where to go from here. Do I write a CustomAuthorize attribute override for Web API and go back to the database and grab the roles. (probably match the DB defined roles to the user based on email address)
OR
Is there a way to implement roles natively with Azure AD V2?
I'm not sure whats the best course of action from here. Documentation and Code samples seem limited. It would sure be nice to just throw a AD User in a Group and have the Group be respected as a Role in the Web API. On the other hand, It's nice to have Role delegation handled within the confines of the Web Application.
Any advice, experience or interest would be greatly appreciated.
Answer
Follow up to my question. #Marc , You're correct, after looking at the token the Roles are not present. Adding Roles to the token seems pretty straight forward. You need to Patch the graph schema to include them, Configure the roles and assign them to users as needed thru AAD.
Or that's how it looks at first glance. After digging a deeper, it requires a P1 or P2 Enterprise license which only costs an additional 6$ per month per user. This will literally double the cost of hosting email in the cloud for us.
Alternatively I wrote a CustomAuthAttribute for WebAPI and tied User & Roles together on the server backend. Roles can still be managed via the web application and users can still login using Active Directory Credentials.
I recall that the id token returned in implicit flow (the one you use with JS) does not include app roles (or groups). I cannot find any docs confirming that but see others who got around the issue (so the issue must be there) by using Graph to get the roles (or groups).
You can capture the token you receive from AAD and view it using https://jwt.ms to see whether roles are included in it.
I'm developing integration with Google Ads API using their Ruby gem library.
I have an approved oAuth2 account for the Ads scope with an approved developer token that allows any external user to connect with our API.
I have a Google Ads account that manages our own Ads account and two other accounts.
When I authenticate with the API and approve it, I then grab the account with
graph = get_accounts_graph()
Apps::GoogleAds::Account.get_accounts_map(graph)
This surprisingly returns just ONE Ads account, and one that belongs to a client that we manage. Our own two Ads accounts are missing.
So I tried to compare between our client's account and our own.
Under https://ads.google.com/aw/accountaccess I can clearly see we have admin rights to our two ad accounts, just like we do to the client account.
Am I missing some setting somewhere? Has anyone experienced this before?
I ran into this issue at the beginning. The sample in the API client libraries (which I'm going to assume you are using here), calls the customer service
customer_service.list_accessible_customers()
There's actually two different services for retrieving customer account IDs. The customer service only allows access to accounts that are added as direct admins on each account. This is an important distinction as manager accounts don't fall into this category.
What you need to call is the regular GoogleAdsService (not the customer service!) and put your request in the query itself..
query = "SELECT customer_client_link.client_customer FROM customer_client_link"
This will give you a list of account IDs as resource names, not accessible accounts. And you can iterate over them as usual.
Hope that helps.
I'm developing something with the Google Books API, but I think this can be generalized across many of Google's APIs.
Suppose I have an app that's got a social aspect where I can add friends and see their Google Books collection. From the API docs, it says I can retrieve anybody's collection if I know their userid, but I can't find any way to retrieve it programmatically. The only thing I can expect a user to know is their friend's gmail address (or Google Account Login, which, for these purposes, is the same thing). The only way I can somehow get it is through a URL on their web interface for Google books. Making users do it that way is an obscure form of torture.
Does anyone know if this is possible with any Google service?
Specifically, suppose I had a gmail address: example#gmail.com, could I then query some Google service to get the userid for that user? A userid is a basically a really big number (around 20 digits)
Here's a similar question with a solution/workaround from Nick Johnson:
The current workaround is to create a
User object, store it to the
datastore, and fetch it again. If the
email corresponds to a valid Google
account, the User object in the
returned entity will have its user_id
field populated.