I wanted to use the same client id and secret from an existing client application which actually belongs to another person and he is no longer with the organization. How can I view that ?
This is actually explained in the documentation:
You must have the Organization Administrator privileges of the master
organization, or must be the owner of the client application to access
the credentials.
To obtain the credentials of a client application:
From the left navigation pane in Anypoint Platform, click Management Center > API Manager.
On the left navigation in API Manager, click Client Applications.
From the details pane, click the application for which you want to view the client credentials.
The client ID and client secret credentials for the selected application appear on the right of the window.
Related
Customer has just implemented a new Azure SQL Database instance. They are using the 'Azure Active Directory Universal with MFA' (multi-factor authentication) security option. I am trying to connect to this database through Azure Data Factory, and nothing works. I've tried all 3 connection string variations, and I'm beginning to think programmatic access is not possible.
Has anyone run into this, and were you successful in connecting? If so, please elaborate -- I expect a lot more of us are going to start seeing this in our work.
Please follow below steps to configure Azure SQL Database Linked Service in ADF using service principal.
Go to Azure Active Directory in Azure Portal and click on App registration under Manage on left side options. Click on + New registration.
In new app registration page, just give Name to your app and click on register.
Once the app created, copy the, Application ID and paste it under Service principal ID in Linked Service. The tenant ID must be already there in Linked service. If not, you can copy that also and paste under Tenant in Linked Service.
For service principal key, you need to create the Secret for newly registered app. Go to Certificates and secret in new app, and click on + New client secret. Once created, copy the Value of the secret as shown below. Copy this Value under service principal key in Linked Service.
Now, before checking test connection, you need to set the registered app as server admin in SQL Server. Go to SQL Server, click on Azure Active Directory on left side. Click on Set admin option, search for the name of the app you have created above. Select the app. Click on Save option.
At last, just check your connection in Linked Service. It should work fine now. Refer below image.
I want to enable G Suite Domain-Wide Delegation of Authority for a new service account. I already had enabled it for one service account a few weeks back. While creating the new service account, I no longer see the option to Enable Google Apps Domain-wide Delegation. I am following these steps: https://developers.google.com/admin-sdk/directory/v1/guides/delegation#delegate_domain-wide_authority_to_your_service_account.
I can't even see that option for the older service account when I click on Edit for that service account
I was already able to do it for one service account, although I no longer see the option to disable/enable it when I click on Edit
If you don't see the checkbox, it means you don't need to enable it. You can get the client ID from the UI or by looking at the JSON private key you downloaded, and use that to authorize your scopes in the Admin console.
I am trying to access the IBM Domino Access Services 9.0.1, which is REST based service for accessing all calendar items.
Lets say for getting calendar items for a user , i have to pass credentials of that particular user.
I don't think it is feasible to store the user credentials in the client side and pass the same while accessing those service instead will create one service account in domino server and access the service using the same service account.
Any idea how to configure in the domino side or how can i achieve accessing the calendar service without passing the credentials of the user.
Looking for similar to what we have are having like Exchange impersonation.
Thanks
Anil
It depends on what kind of application you are building. If each Notes calendar owner logs in to your application directly, it is possible to store the user credentials on the client side. Of course, your application would be responsible for securely managing the credentials. On the other hand, your application might require access to each calendar without directly involving the calendar owner. This can be the case for server-side applications.
Your question doesn't specify, so I'll assume yours is the second situation. In that case, you could create a user identity for your application and then add that identity to the Access Control List (ACL) for each mail file. There are two ways to modify the ACL: 1) You can change the design of the master template and let the design propagate to individual mail files, or 2) You can ask each user to delegate access to your application's identity.
The bottom line is the Domino calendar service acts on behalf of the authenticated web user. If that's the calendar owner, the calendar service will have full access to the calendar. If the web user is some other identity, access will be limited to the rights granted in the ACL. For more information about the ACL see this tutorial.
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
I am using a Oracle SSO server to authenticate users of my APEX app. I wish to display user's first name and last name on my app, I don't want to ask the users for this info. How can I get this info from SSO server ? Do I have to read cookies?
When using SSO, this information is typically passed in to your application through a custom header. You should be able to configure the SSO provider to pass the user name back to your application through the header, and the client side of your application should have an API for withdrawing it from there.
It depends how your Identity Provider (IP) is configured - in our case, the encrypted artifact passed to our application (via a cookie in our case, but could be passed in the querystring or posted to your app) contains the information about the logged in user that our IP has configured to send to us.