I am trying to integrate OKTA as service provider to provide access to the custom application for external customers.
External Users login to enterprise Idp to access the custom application
After successful authentication IDP triggers the IDP-Initiated flow and submits the SAML response to OKTA
OKTA checks for the external user information in the SAML assertion and sends these details to Custom API application to identify the user
If the user is found, the API returns the required information to OKTA
OKTA will initiate the PKCE flow to provide access to the custom application
I was success in configuring the OKTA and external customer IDP. But, Can anyone knows how OKTA will call the custom API application to identify the user information? Also, how to configure the redirect URL?
unfortunately I don't have an answer to your question as we use PingFederate but I was curious as to how you setup Okta (as the SP) to accommodate the IdP-Initiated call, without having to call back into the IdP for authentication? I ask because, as the IdP, we are calling Okta (as the SP) and the SAML response but the vendor is stating they cannot setup Okta without the IdP URL to call back into to have us, the IdP, authenticate the user. Seems your setup works how we believe it should so wanted to get more details about this.
Related
I have an ASP.NET Web API (v4, specifically) application that currently authenticates using Forms authentication (through a SQL membership provider (i.e. using aspnet_Membership, aspnet_Users tables and all that)). It's basically the backend API hub for a bunch of other applications.
Alongside that, I have a third-party application, SP (for service provider), which supports SSO and single logout using SAML. My goal is to set up a SAML identity provider that can receive a SAML single logout request, which would in turn send a logout response to SP.
I started out looking at Auth0 to achieve this, but I am confused about what role Auth0 would actually play as the identity provider since all of my user creds are stored in my own database. Is there some way I can supply Auth0 (or any of these identity providers) with my user creds store for it to authenticate my users? Or is this not desirable/possible and I need to make my existing app to be the SAML identity provider?
To use SAML in your client application, you need a SAML stack.
So you could add the stack and it would be self-contained.
Both identityserver and Auth0 can use a SQL DB as the authentication store. They both support the SAML protocol.
Once you have done the SAML configuration, you just need e.g. a login screen where the users decides local authentication or SAML authentication (this invokes the IDP and that would do the SAML side for you).
I have a portal application developed using spring security and mvc framework. This portal application connects to IDP (Developed using Spring security and spring saml) for authentication. if the user authentication is success,user will be navigated to homepage where multiple links are provided for external applications… When the user clicks on the application link, user should successfully navigated to the respective application without challenging login page.
Other applications are developed using struts and spring security. How do I make sure that when a link is clicked from the portal, either saml token or context is passed to other application so it will not ask for login.
Any help is greatly appreciated.
The most common flow for SAML is something like the following:
Application (called service provider, or SP) receives request (any request, like request for a business resource) from unauthenticated user
It redirects the user (most commonly via http redirect) to the IdP (in which the SP should already be registered)
If the user is not authenticated to the IdP (not logged in to SSO), a login form is presented and login is managed by the IdP until there is a user session with the IdP
If the user is already authenticated with the IdP (because either he was already or entered a correct user/password), the IdP issues its claim token and posts the user with the token back to the Assertion Consumer Service in the SP (the original application)
The Assertion Consumer Service (practically just an API endpoint) receives and validates the SAML token and creates an own application session with the user. Now the user is authenticated to the application (SP)
Upon the next request to the application (SP), there is already a session, so SAML is not involved
Note that if there is already a session with the IdP, all of this is seamless for the user. A bunch of redirects take place, but the user will just reach the application without entering credentials.
So the short answer to your question is that your external applications need to support SAML SSO and need to be registered with the identity provider, in which case they can just use the IdP for authenticating the user and signing the claims it may have.
I have an application that: a) authenticates the user via LinkedIn, and b) authenticates access to the Linkedin API http://api.linkedin.com, through oauth. The issue is, my ouath authentication is not allowing me access to the general LinkedIn site, http://www.linkedin.com.
For example, this works:
https://api.linkedin.com/v1/people/~?oauth2_access_token=AQXSs5c6R-6e_F3 ...
... but, this does not:
https://www.linkedin.com/?oauth2_access_token=AQXSs5c6R-6e_F3 ...
Can someone please explain the limitation here?
REF: Another conversation I am having, on the same topic.
I think you are a bit confused here about Oauth. Oauth grant you access to make request on behalf of user for a service provider (LinkedIn in your case). This is exposed as an api by service provider.
So you can make request only from https://api.linkedin.com (Step 4)
What you are trying to do is make request from site. But that's not how Oauth works. Oauth works for only providing api enabled by service provider.
Your token can make only selected requests that are exposed by LinkedIn for developer to make their applications base on their api.
Moreover, request type that you can do also depends upon the scope that you set in application configuration. This token doesn't grant you site wide access. Only access to those apis which are under the scope. There's no site wide scope to enable you to make any call.
Do remember to set appropriate application configuration before proceeding.
To view complete list of api calls that you can make, check here
I had a requirement to implement spring security saml implementation.
And I want to connect to IDP(Identity Provider) to authenticate without using IDp's login page. In my case, I want to use Service Provider (login page)..
Is this possible? If yes how to achieve this?
You can try with WSO2IS with request path authenticators which validates user credentials comes from SP login request. If you take SAML2 SSO scenario, SP can send SAML2 Auth request using POST binding to IDP. In the same request SP can send the end user's credentials that is retrieved from the login page of SP application. Then you would not see the login page in IDP and credential are retrieved from auth request and validates with IDP's user store. If success SAML2 response is generated. You can take help from this link.
This is not really a good idea since by definition, the service provider is not supposed to authenticate users, that is the IDP's responsibility.
If you are concerned about branding.. you may be able to request the IDP to personalise their login page if your SP has requested authentication although it is slightly unlikely that they will agree to this.
I've been working whit the SAML extension to connect to an ADFS server. I've hacked the sample application to use my ADFS server and everything went well, but I would like to know if there is a way to connect to an IDP without using the loging page of the IDP. I mean if there is a way to do this process in background for the end-user. I am thinking about doing a query to ADFS or something like to get the users and do authentication from the SP login page, avoiding the need for the user to authenticate in the IDP login page.
The purpose of federated authentication is to delegate it to a centralized server in such a way that the relaying parties/service providers do not have access to user's credentials. Enabling authentication directly in your application would violate this principle and for this reason is not supported by neither Spring SAML nor ADFS.
If you want to authenticate your users directly, use authentication directly against Active Directory instead of ADFS. This will fully support your use-case.