Does Azure Active Directory B2c (adb2c) support connection to 3rd party Identity store using jwks endpoint and identity store? - azure-ad-b2c-custom-policy

Does Azure Active Directory B2c (adb2c) support connection to 3rd party Identity store using jwks endpoint and identity store?
We are using custom policies of the IEF(Identity Expirence Framework) of adb2c.
In that we need to connect to 3rd party Identity Store which does not support client secrets.
They only support jwks endpoint and expect client assertion to be passed on to them while connection from adb2c custom policy to their store?
Is this supported in adb2c IEF?

Related

Azure Batch tasks integration with Azure REST API

We have REST WEB API hosted on Azure(OAuth2.0 in place). If I have to call the REST API from Azure Batch Tasks, I guess I need to pass some access token so API can authenticate the call from batch service. Need inputs on how to implement, please note we are using BATCH .NET SDK(not Batch management library)
The current recommendation for authenticating with other Azure services is to give a service principal permissions for the APIs and then using a managed identity to authenticate with that service principal.
If your API only supports key based authentication then you can upload a certificate and add it to your pool. That certificate could then be used to access Azure Key Vault with the relevant keys (https://learn.microsoft.com/en-us/azure/batch/credential-access-key-vault).

How can I keep my identity server session in sync with an external identity provider?

I am using IdentityServer4 to provide SSO and SLO to several web apps. The user may sign in to the identity server through an external OIDC provider such as Azure AD. The external provider, identity server, and web apps are all configured to use persistent sessions that last for weeks or months at a time.
This setup works fine and the user can sign in as expected. The issue is I have a requirement for all sessions to stay in sync, so when the external provider session expires, the expiration propagates to my identity server and then to my web apps.
This requirement is to ensure that none of the sessions further down the chain outlive their provider's session which would break SLO functionality. For example if my identity server session outlives the Azure AD session it depends on, the user can sign into Azure AD again, but will not be able to SLO from my identity server and web apps through Azure AD since the Azure AD session has changed, and my identity server depends on the now-expired Azure AD session.
I am able to enforce this requirement between my identity server and web apps using a check_session iframe and passive authentication requests with prompt=none. But I cannot figure out how to enforce a similar type of requirement between an external provider and my identity server in a way that will both end my identity server session and notify my web apps.
How can I keep my identity server session in sync with an external identity provider? If this is not possible, what is a correct approach to ensuring SSO and SLO sessions do not get out of sync between the external provider, identity server, and web apps?
The solution for this is federated signout
Federated sign-out is the situation where a user has used an external identity provider to log into IdentityServer, and then the user logs out of that external identity provider via a workflow unknown to IdentityServer. When the user signs out, it will be useful for IdentityServer to be notified so that it can sign the user out of IdentityServer and all of the applications that use IdentityServer.
To implement you need to set RemoteSignOutPath when adding AzureAD as external IDP.
services.AddAuthentication()
.AddOpenIdConnect("aad", "Azure AD", options =>
{
options.ClientId = "<Your Application (client) ID>";
options.Authority = "https://login.windows.net/<Directory (tenant) ID>";
options.CallbackPath = "/signin-aad";
options.SignedOutCallbackPath = "/signout-callback-aad";
options.RemoteSignOutPath = "/signout-aad";
});
here is a nice blog explaining it with IdentityServer4 (reference blogs on the bottom are very useful too)

3-legged oauth with Wso2 API Manager

I need to expose some APIs through wso2 api manager, but with three important features:
Some APIs need 3-legged oauth access control;
The oauth authentication must be made through an identity provider already configured in wso2 identity server;
Need to give the resource owner the ability to manage (list and revoke) subscribed applications
Can anyone give me some tips to achieve this scenario?
Configure Three Legged flow with OAuth 1.0a.
Refer http://tharindue.blogspot.com/2015/04/three-legged-oauth-10a-playground_23.html for more details
If IS as KeyManager is configured on APIManager, Identity Server is the Identity Provider.
When a developer create an application on API Manager Store, he has manage permissions to that application. All other subscribers use the key and secret pair,  has subscribe permission only.  
For additional informations:
http://wso2.com/library/articles/2016/05/article-the-benefits-of-integrating-wso2-identity-server-with-wso2-api-manager/
https://docs.wso2.com/display/IS460/Authorization+Code+Grant+Type+with+API+Manager

WSO2 IDS: Can I add third party's IDS as my Trusted Identity Provider, if so how?

We are using WSO2 Identity server for our product. As for as our applications are concerned, we're authenticating the users with the IDS. We now want to integrate with third party product. And we suggested them also to use WSO2 IS for their identity service [auth/auth]
When I send a request to third party application, their application should authenticate our application request and accept the request. Can they add our identity provider as their trusted authentication provider, and that would help the user request getting authenticated against our identity source?
Is this possible? If so, please point me to sample where it is done!
Yes. It can be done in different ways. As an example, Your 3rd party application is a liferay, You can use WSO2IS as openid provider. Because liferay allows to login to it portal using openid. Else your 3rd party application supports for SAML2 sso, WSO2IS can be used as SAML2 SSO provider. If 3rd party app, is IIS hosted application, you can use Passive-STS.
Also, if 3rd party application does not support any common standard, there may be extensions that can be used to extent their authentication mechanism. If that case, you can write extension to 3rd party application, to call WSO2IS API. Because all APIs are web service APIs.
You can find more detail of integration
[1] OPENID : http://www.soasecurity.org/2010/08/sign-up-with-openid-providered-by.html
[2] SSO : http://tanyamadurapperuma.blogspot.com/2013/09/configure-wso2-identity-server-saml2.html

Authenticating calls to my Web API from third party applications with Azure ACS

I'm using Azure ACS for authentication to my Web API project and it's working great with IP's such as Google and Live. I have a requirement to allow third party (partners) to develop against my API but I'm not exactly sure how to authenticate them. I'm thinking I may have to write a custom STS and manage usernames and passwords for each partner. In this scenario the partner would request an access token from my custom STS via a username/password and than use that token to access my API. Also I see Azure ACS has Service Identities, I'm wondering if I can use them in order to authenticate to my API?
Yes, you can.
Create Service Identity with authentication by x509 certificate
Create Rule Groups with rules where mapping Service Identity Name to selected claim
In your application in Relying party applications check new Rule Group in Authentication Settings.