I'm adding SSO feature to my service to allow customers login with their AD accounts. To provide this I use SAML component from componentpro.com
What is correct way to perform security interaction:
From IdP side: what should customer provide to my service besides IdP url? Any certificate that just contains public key?
From SP side: what should I provide to customer?
Choosen SAML tool uses certificates to sign SAML request to IdP and to decrypt assertion from IdP. What are that certificates (from previous questions)? Is it the same certificate for signing and decrypting?
Update: useful link about using certificates in SAML communication.
Normaly this is set up using a SAML metadata file that contains the IDP endpoints, keys etc. Your service then sends a similar metadata file with information about your service to the IDP
If the customer is the IDP then as above you usually provide them with a metadata file.
It is gennerally a bad idea to use the same key for signing and encryption. Read the discussions here and here
Related
I have a requirement to provide API to our consumers. The intention is to secure the API using AzureAD B2C - Client Credential Grant flow.
I have created a custom policy on B2C tenant that provides the access token. Things work fine with the clientId and Secret authentication method.
I now want to secure the OAuth2 conversation further by allowing the client to use the signed client_assertion as opposed to static client secret using their protected key. I have uploaded the public portion of the key into the relevant app registration.
Unfortunately, consuming the /token endpoint with the signed client_assertion results in an error.
REQUEST
https://tenant.b2clogin.com/tenant.onmicrosoft.com/b2c_1a_demo_clientcredentialsflow/oauth2/v2.0/token
grant_type=client_credentials&scope=https%3A%2F%2Fapi%2F.default&client_id=d5339984-e6c7-457a-9ef9-21fb6e3e6c59&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=eyJhbGciOiJo
RESPONSE
HTTP/1.1 400 Bad Request
{"error":"invalid_request","error_description":"AADB2C99027: Policy 'B2C_1A_Demo_ClientCredentialsFlow' does not contain a AuthorizationTechnicalProfile with a corresponding ClientAssertionType.\r\nCorrelation ID: 5eb76fa5-c919-4877-a722-0d38408e18c6\r\nTimestamp: 2023-01-19 07:38:25Z\r\n"}
Can someone please tell me if B2C is intended to support client assertions? Metadata JSON on the policy returns only the following two authentication methods:
"token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ]
Is it possible to include private_key_jwt as a supported authentication method using custom policy configuration? Is it possible to configure the AuthorizationTechnicalProfile for the policy with a corresponding ClientAssertionType?
I hope that I have explained the problem well enough.
I have tried various strategies, incluling the use of AAD token endpoint, login.microsoftonline.com with the B2C tenant Id. Using that endpoint, the custom policy on B2C is completely ignored, therefore generating a vanilla token with none of my curated claims.
TLDR: As of June 2022, Azure AD B2C does not support client assertions.
This issue on Github asks for documentation for error number AADB2C99027. In the course of the discussion, a member of the team states
Unfortunately, we decommissioned client_assertion flow because it didn't follow OIDC spec – So we shouldn't be documenting the error.
From that, I take that there are no plans to support client_assertion flow.
I want to enable my API to start accepting tokens issued by any identity provider (like other Azure AD, Okta - I'll keep client ID and authority in my settings), one request comes for Azure another will come for Okta, so by looking at the token, I should be able to validate it and send response.
Any right approach or technical correction you can suggest?
in progress code file- start.cs
I am trying to understand how smartcard auth happens over Azure. I Understand that we require on-Prem ADFS however I am trying figure out two things:
1) What exact exchange takes places between Azure and client? Something like below:
GET https://login.microsoftonline.com/{tenant}/oauth2/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token+code&redirect_uri=http%3A%2F%2Flocalhost%3a12345
&response_mode=form_post&scope=openid&resource=https%3A%2F%2Fservice.contoso.com%2F&state=12345&nonce=678910
2) How is Smartcard Authenticated? Is it a challenge response or the certificate is verified? In case of challenge response the client generates a signed data that is verified by ADFS?
1)What exact exchange takes places between Azure and client?
The sample request you mentioned is a sign-in request to get access tokens, for the exact exchange between Azure and client, just refer to this link.
2) How is Smartcard Authenticated? Is it a challenge response or the certificate is verified? In case of challenge response the client generates a signed data that is verified by ADFS?
I think it may be a challenge response, and the client will generate a signed data that is verified by ADFS.
You could refer to this article, as mentioned in the How federated access works with Windows Azure (Step 4) :
The KDC issues the client a Service Ticket, containing the multifactor claims (this assumes that IT policy forced smartcard authentication at desktop login time, otherwise, AD FS can challenge to present a smartcard during this Windows Azure Management Portal login sequence).
The client PC presents the Service Ticket to AD FS. AD FS validates the Kerberos ticket and generates a signed SAML token for Windows Azure AD in the next step. AD FS will only send the signed SAML token if the credentials are valid.
Given a service like Okta, is it possible to use raw SAML requests to get a list of users from my Okta domain? We are hoping to use SAML to retrieve users from Okta and generate linked accounts based on those Okta users for them to sign in to our system using SSO, but we need user accounts in our system that are linked to Okta accounts, or any other SSO/SAML/idp provider.
You cannot do that with SAML. SAML allow user to access other applications from the IDp.
You will need to use their API and authenticate using Oauth, no SAML.
https://developer.okta.com/docs/api/resources/users.html.
What about using Just in time user provisioning based on SAML assertion attributes?
SAML is an Authentication/Authorization protocol, not a user management protocol.
If you're using OneLogin, check out their APIs: https://developers.onelogin.com/api-docs/1/users/get-users
We are looking to implement SAML based IDP(with signed response & encrypted assertion) in Azure and our SP will be some another service. For this, we need to configure our SP public cert at IDP side in Azure. We have created basic IDP with "Azure Active Directory>>Enterprise applications>>Non-gallery application". So now we need to know, how we can configure SP public cert at IDP in Azure?
You don't have to configure your SP public cert in Azure AD. Azure AD will ignore the signature in the SAML request. The only thing you need to configure in Azure AD is Identifier, Reply URL and add any custom attribute expected in the SAML response. Then, use the metadata or certificate to configure SSO on the SP.
Take a look at these docs:
Azure AD Single Sign-On SAML protocol
In case you want to list your application in the AAD Gallery for allowing common customers to add and configure your application: Listing your application in the Azure Active Directory application gallery
Signed Response
Azure AD has an option for signing its SAML Responses. Just make sure you download Azure's metadata to grab the Azure's signing certificate.
Encrypted Response
Azure AD calls encrypting the assertions inside the SAML Response, to be Encrypted Tokens which is really not a very good name at all. It is also unfortunately not with the rest of the SAML options. This page explains how to do it. You will need to have your SP enc cert in a PEM format. The rest should be simple.