I am trying to integrate Azure B2C as the IDP with a number of legacy applications using SAML SP initiated Flow where I need to pass as attribute with the AuthRequest which I will use in a service call during login from within the custom policy.
I am wondering is there a way to use the relay state for this or does Azure B2C support SAML Extensions to support this use case?
I know I can do this with OIDC but my applications do not support this currently :(.
Kind Regards,
Lastbuilders
Try passing the value in the relay state parameter from SP Initiated flow and then reading it using {SAML:RelayState}claim resolver within the policy.
Related
I am using Azure Active Directory Business to Consumer(adb2c).
We have designed custom policies, part of Identity Experience Framework(IEF) of Azure for 2 different applications.
One application is using login policy/flow which connects to a 3rd party Identity store.
Another application is using login policy/flow which connects to a different 3rd party Identity store.
Can we achieve SSO between them?
I am trying to use DefaultSSOSessionProvider session provider to skip technical profile which actually connect to 3rd party IDP and complete the login in case of SSO scenario. Getting exceptions while doing this.
Will this be possible or is there any other approach to achieve SSO?
In order to enable SSO for different applications in Azure AD B2C you need to configure SSO at the tenant level. To be able to skip external IdP selection you need to set a TP that leverages the ExternalLoginSSOSessionProvider in the UseTechnicalProfileForSessionManagement attribute of your external IdP TP. Take a look to the following custom policy permalink for a sample.
Finally, the external IdP SSO is controlled by the IdP itself and not by B2C so if some problem arises ensure the IdP SSO is working before validating B2C SSO.
I created azure b2c custom policy using SAML flow and cannot find documentation what logout url should I use on SP side. What I see in saml policy metadata xml:
<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://tenant.b2clogin.com/tenant.onmicrosoft.com/B2C_1A_signup_signin_saml/samlp/sso/logout"/>
it does not work with my SP (zendesk) and shows error after logout redirect: AADB2C99046: The logout request does not include a session index. I investigated saml logout request and it does not contain session index element. As I understand SAML standard documentation SessionIndex is optional.
Is there any way to fix log out functionality with SAML?
here is the answer from Microsoft support:
After analyzed your request with our technical advisors and additional
resources, we got a confirmation that for your particular setup which
is having your B2C actuate as SAML Token Provider, the SessionIndex
along with NameID is a must and needs to be provided by your Service
Provider.
I know it is hard to track what requirements usually needs the setups
in B2C by having the information spread everywhere but in Azure AD B2C
the following are the two scenarios supported:
Have Azure AD B2C acting as an IdP and achieving SSO with SAML-based Service Providers
Have Azure AD B2C acting as a service provider (SP) and interacting with SAML-based identity providers like SalesForce and ADFS.
The first scenario (1), that one you have, it requires your custom
policy to setup your SAML token issuer, along with the
SAMLSSOSessionProvider the TechnicalProfile named as SM-Saml-Issuer.
SAML session logout will not work then without your SessionIndex and
NameID attributes coming from your SP.
This is the only way to achieve a successful SAML logout call from
your Service Provider.
Let me know if you have any questions, I can then review this and
forward it to our experts if necessary.
Best regards,
_____________________________________________________ Victor J. Hernandez | Support Engineer | Azure Support
Most SPs using SAML will create their own session after you are authenticated. This session is only used by the SP that set it up. To do this, logout must do the following: delete all SP sessions.
The only truly reliable way to completely log out of SAML SSO is to delete all sessions, including identity provider sessions and all service provider sessions. Normally, this can be done simply by closing the browser.
We are running some tests on Keycloak to implement it on our company and I am are wondering what is the best approach to make Keycloak interact with our legacy system.
In our scenario, we have a native login interface and we are going to use direct grant - we are not going to authorization code flow / redirect flow using a browser and we don't have any kind of social login.
The other point is: we must to keep our native interface.
Based on that, what is the best/right approach to implement this flow? I have set my client on Keycloak with direct grant but the problem is that every user must exists in Keycloak. Isn't possible to use Keycloak as a "token emissor" instead of IDP?
In case of Keycloak must be an IDP, what is the right approach to allow Keycloak log in legacy system? Should I implement a custom Identity Provider? Will mobile make a login request to Keycloak or to legacy system?
Keycloak must somehow be able to either authenticate the user or delegate the authentication of the user to a federated identity provider. A few options:
If you want to use Keycloak as an identity provider, you could do
this by migrating your user base to Keycloak, or by making use of
User Storage Federation, which means Keycloak will use your existing
user database as a source. In this case, the login interface will be
a Keycloak interface (which you can customize to your wishes). See:
https://www.keycloak.org/docs/latest/server_admin/#_user-storage-federation
Another option is to convert your legacy system into an identity
provider that complies with either the OIDC or SAML protocol, and
set it up as an identity provider for Keycloak. In this case you can
keep your existing login interface, but it will probably require
quite some changes to your legacy system. See:
https://www.keycloak.org/docs/latest/server_admin/#_identity_broker
I'm doing a technical assessment for a job interview. It's called on me to walk through implementing a client using OneLogin (IDP) into our software (SP) with SSO.
The activity is asking me to include 3 things:
Service Provider
Identity Provider
Generate and distribute the sp metadata to the client
I'm using https://www.samltool.com/sp_metadata.php to generate the metadata but I'm wondering what the purpose of this doing this when this SP is already a verified app on OneLogin?
OneLogin's knowledge base here doesn't indicate the need for the SP metadata to implement. It doesn't even call for any SP entity's or endpoints. It seems like I would need the idp metadata as the endpoints use a unique value but not the opposite. So am I right in assuming that generating and sending the client the SP metadata is useless? Or is there a reason for it?
If you're using a Onelogin catalog app, you often don't need any instance specific metadata from the SP. The catalog apps are supposed to shortcut and simplify configuring a standards based SAML supporting SP. Some of the Onelogin catalog apps sometimes need some metadata, such as a RelayState parameter as per the SP requirements. If a catalog app doesn't exist and you're building a custom SAML app in Onelogin, you'll need the SP metadata in full.
We maintain a website that uses the built-in .NET Core / EF Identity model so all user data is in DB tables. We now have a need to support SSO into another 3rd party system which requires that we host our own IDP with support of SAML 2.0. We don't want to change our identity model or login process for our own website, we just need to return a SAML Response for a user without our website as a response to an SSO request by the 3rd party website. Our site is hosted in Azure as a Web App but we don't use Azure AD for this website which is public facing for external client employees.
Are there any recommendations to create a simple IDP that maps to our existing AspNetUsers database table to retrieve and prepare an SSO Response but doesn't impact our existing identity setup? In all likelihood, we'll have to support other SSO protocols in the future with the same implementation. Do we need to go as far as to implement IdentityServer4, making the existing web app act as both an IDP and a client app?
idsrv4 supports the EF identity model (AFAIK). If it doesn't you could always write your own plugin.
idsrv4 then becomes the IDP and will authenticate against your current DB.
idsrv4 has SAML and WS-Fed plugins to support future SSO.
Your other choice is to implement something like Auth0 that supports authentication against local DB and has full support for SAML and WS-Fed.