I’m new to Apigee X. As Apigee X can also act as an Authorization server. I have the below queries:
When to use Apigee X as an Authorization server?
Pros and cons of using Apigee X as an auth server.
Suppose an organization already using 3rd party authorization server such as Azure AD. Is it a good choice to suggest Apigee as an Authorization server? If yes, What factors should be considered before opting for Apigee as an Authorization server?
Kindly help!!
Thanks in advance
Related
So, we have made a web application login protocol via which users can query a database on Azure SQL Server with sensitive data. Now partner-organizations want to use the same app to query their own databases on their own Azure SQL Server.
Is there a way where we can ensure that as admin + host of the web application we don't have access to their sensitive data, while we are able to send user from the correct Identity Provider through.
Until so far I found the OAuth 2.0 Token Introspection, specifically this implementation: https://wiki.surfnet.nl/pages/viewpage.action?pageId=23794471. Is there a way to implement this within Azure around the Azure SQL Server (if needed via a very simple API)?
Azure built-in reader role:
View all resources, but does not allow you to make any changes.
EDIT: If the problem is security you need to solve it through security countermeasure like Always Encrypted:
This provides a separation between those who own the data and can view
it, and those who manage the data but should have no access -
on-premises database administrators, cloud database operators, or
other high-privileged unauthorized users.
I have Django web app, with an SQL server db, deployed on my Azure subscription. I need to connect/authenticate my Web App to SQL server (still on my Azure subscription) but I can't using username-password on my code.
How can I do it? By key vault? By Azure AD?
Thanks!
I saw that the best approach is to use the managed identities. My webapp can connect to the database using a AAD identity automatically provided by Azure. This is secure, without you needing to implement all kinds of difficult set-up.
Thank you again!
I have many PG servers using LDAP authentication.
When I got request for new user, I create user account in every PG server so that LDAP can be used for authentication.
But, I wonder is there better way to manage accounts.
Why don't you implement one LDAP-Server as central authentication provider?
I'm setting up Single Sign On for Jaspersoft Server to work with Azure AD. I found in the Azure Market we have jasper server supported
https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aad.jasperserver?tab=Overview
but I can't find any relate document in anywhere. I think my approach may not correct.
Any advise is really appreciate.
Thanks
The app today can be used with Azure AD for password based SSO.
This doc talks about password SSO. If Jaspersoft supports SCIM, AAD can do provisioning to them.
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/application-sign-in-problem-password-sso-gallery#configure-the-application-for-password-single-sign-on
Scenario: In an intranet application, ADFS uses AD for authentication(Account Store) and Sql server for authorization(roles/Attribute Store).
The roles are my own application specific. There are other applications that need to use ADFS. If ADFS is configured to use my SQL Server to fetch roles, what would other applications do? How will they manage their authorization?
Is my understanding correct? If yes, please verify my answer:
Ans: ADFS just returns me the AD identifier(SID/Name).I map this to my sql server roles. Role management should be done by my own application connecting to Sql server. Use session to prevent hitting DB for authorization every time.
To avoid hitting the SQL server for every authorization check, you could implement claims based authentication. Use the SQL attribute store to add your role claims to the AD user ID claims. The resulting claims ticket (SAML) is sent as a cookie and isn't fetched on every authentication check as it is kept as a cookie by the user browser available to the server on each and every request. The timeout/refresh can be set by ajusting the claims ticket TTL (time to live).Just a suggestion... =o)