We have in incoming SAML2 response (for an IDP Initiated flow) to our service application.
As Part of our process once we validate the SAML Response, then we need to sign the user into our Identity Server to have a valid session for the user on our Identity Server to allow them to access various resources in our domain.
Is it better to process the incoming SAML2 response on the service application the user requested or on the Identity Server itself
I fell the Identity Server should be more secure and not exposed with endpoints (except internally in our domain)
So would it be a good practise to accept the incoming SAML2 response into our Service application, then send the response to the Identity Server to process and create a session on the Identity server, and then send the user aback to the Service Application they wanted access to ?
Related
has anyone successfully configured OKTA as Identity provider (IDP) in Azure Active Directory so that token recieved from OKTA can be leveraged by apps in Azure.
I have gone thru several stackoverflow queries but none has any step by step guidance on how to add it in Azure AD as an external IDP.
any help?
thank you
• Yes, you can configure Okta as an IDP in Azure as a federated identity provider but please ensure that it supports SAML 2.0 or WS-Fed protocol for direct federation to work. Therefore, to proceed further, ensure that organization using Okta as an IDP has its DNS records correctly configured and updated for the domain to be matched with the target domain or a host within the target domain in case of a passive authentication URL.
Once, the DNS records are setup correctly for an IDP’s domain name, then configure the partner IDP with the required claims and relying party trusts such that their SAML metadata file or URL is retrieved and uploaded for adding the Okta using IDP as an external identity as shown below in the snapshot: -
• Once, you have configured the SAML/WS-Fed supporting Okta IDP as a partner/external identity provider in the Azure AD tenant, ensure to configure specific attributes and claims to be configured at the third-party IDP such that these attributes are received in the SAML 2.0 response from the IDP itself when any user tries to login to the Azure AD using Okta identity.
Ensure that the below attributes and claims are received as information in the SAML token from the configured Okta IDP: -
AssertionConsumerService, Audience, Issuer, NameID and http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
From the above snapshot, ensure to fill the following details for configuring the Okta IDP as an external identity provider: -
a) Issuer URI - The issuer URI of the partner's IdP.
b) Passive authentication endpoint - The partner IdP's passive requestor endpoint.
c) Certificate - The signing certificate ID.
d) Metadata URL - The location of the IdP's metadata for automatic renewal of the signing certificate.
Thus, in this way, you can add an Okta based IDP in Azure through federated external identity. For more details regarding this, I would suggest you to please refer to the below links for more details: -
https://learn.microsoft.com/en-us/azure/active-directory/external-identities/direct-federation#step-1-determine-if-the-partner-needs-to-update-their-dns-text-records
Okta as IDP in Azure AD
As I understand that for getting selective authorization for a protected resource using Azure AD based OAuth 2.0 mechanism, client application need to mandatorily provide the scope URL for getting access token.
Other parameters usually include client ID, client secret (in case of Service Principal auth flow), Azure AD username and password, etc.
SqlClient has integrated Azure AD OAuth mechanism with SqlClient for authorizing a database connection.
So, I guess SqlClient also need these parameters for establishing an connection to Azure SQL server using Azure Active Directory authentication method.
But I don't see that it accepts any scope from the client application.
How does SqlClient gets scope for a particular Azure SQL server instance? I see that it gets something as Federated Authentication Info from server but I don't understand it completely.
The scope required for SQL Servder Authentication access tokens is https://database.windows.net/.default which stands for default scopes/permissions for https://database.windows.net/ resource.
Once an access token is obtained you pass it trough the SqlConnection.AccessToken property.
I am working on a mobile app that currently has the Intune SDK integrated app itself. This Intune SDK forces a user to log in using their company credentials and in response a subject ID and an Azure AD token is set in the app session.
I would like to integrate this app with an Identity Server instance using the client credentials grant, but in addition to the client id and password, I would like to pass along the Intune Azure AD token (and have it validated by the Identity Server) as a better level of security than the client secret (which is compromised by being in the app code).
What would be the best approach here?
Here are my thoughts on options:
Create a custom grant type that accepts client id, client password and the Azure AD token? What's the best way to approach this, if so?
Create an ISecretValidator implementation that checks if a password is an AAD token first, then validates the token if so. Does this introduce security concerns?
WSO2 Identity Server fails to perform authentication SAML2.0 consumer URL not reachable
We are using WSO2 Identity Server 4.6.0 for SAML 2.0 based Single Sign-On.
The authentication was working fine when the Assertion Consumer URL of the service provider was directly "accessible" (network connectivity) from the WSO2 IS node.
However, I get an error if I register a New Service Provider with an Assertion Consumer
URL which is not directly reachable from the Identity provider : WSO2 IS , but accessible
from the requesting user agent i.e. browser.
The User Agent request gets redirectd to the WSO2 IS (login,do?SAMLRequest=nZP... )
But the POST /commonauth failed with the following returned Status code 302 and Location header Location: authenticationendpoint/samlsso_notification.do?status=Error when processing the authentication request!&statusMsg=The message was not recognized by the SAML 2.0 SSO Provider. Please check the logs for more details
For example the Assertion Consumer URL provisionned was refering to a private ip address only accessible from the requesting browser).
I also tried to provide a hostname instead without success.
Here below is the error we get from the WSO2 IS logs :
TID: [0] [IS] [2014-06-10 17:54:52,344] ERROR {org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet} - The value of sessionDTO is null. This could be due to the hostname settings {org.wso2.carbon.identity.sso.saml.servlet.SAMLSSOProviderServlet}
From the browser :
SAML2.0 based Single Sign On
Any idea why the autentication request failed and why the SSO provider complains about "unrecognized message".
Thanks for your support
JS
If you have fronted Identity server with a proxy server or load balancer Please try to configure severs proxy configurations.
[1] http://soasecurity.org/2014/04/11/handling-server-redirects-when-it-is-a-proxy/
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)