I'm trying to understand the basic flow of an IdP-initiated SSO from a developer's point of view. I am also trying to trace this flow from the sample application provided together with the .NET Integration Kit.
Based on this link:
http://documentation.pingidentity.com/display/PF610/OpenToken+Adapter+Configuration
The PingFederate SP server parses the SAML assertion and passes the user attributes to the OpenToken SP Adapter. The Adapter encrypts the data internally and generates an OpenToken.
Question: How does the PingFederate server parse the SAML assertion? Do I have to code it from the SP server? Or will the set-up of the PingFederate server do the parsing?
What I know for now is that I need to develop the part that parses the OpenToken that is returned by the PingFederate server.
Found this video that provided answer to my questions.
https://ping.force.com/Support/PingIdentityVideoLibrary?id=1011570451001
It turns out that no coding is needed for the PingFederate server, we just have to configure it both for the IdP and the SP side so that they can communicate.
Related
I have an web application made using servlet and I have an seperate API for the web application. I want to secure the API with OAuth so that when we use OAuth, a client certificate is sent instead of credentials to the authorization server for verification and after verification the access should be allowed to the API. Is there any ways to implement this authentication. If possible what are the steps should I do to achieve this?
Client certificate credentials can be used for confidential clients, in either the code flow or the client credentials flow. This type of solution is often used in financial grade setups, where high worth data is involved.
Access tokens issued then contain a cnf claim, so that every API call is bound to the strong credential used at the time of authentication. See the RFC8705 standard for further details.
For a worked end-to-end example that you can run locally, and which covers both the
backend and client behaviours, see this Curity code example. Not all authorization servers support these flows, so check for your provider.
I am building Web API with ASP.NET Core hosted on IIS that will act as proxy integrating a few services.
I need to forward user credentials/identity to specific services managed by my API and to do so i want to enable ticket forwarding in Kerberos.
What steps i need to take to make it work?
First of all I need to setup my service as trusted in KDC and after that should it will received forwardable tickets instead of regular ones (i need to specific services that my API can forwards tickets to), am i right?
How do i then forward that ticket to other service using HttpClient?
Does attaching received token to request will be enough?
Am i correct about listed by me steps and is there any thing more to do?
Thank you all for help.
I have read the PingFederate documentation and it says:
An SP adapter is used to create a local-application session for a user
in order for PingFederate® to provide SSO access to your applications
or other protected resources. You must configure at least one instance
of an SP adapter in order to set up connections to IdP partners. You
can also configure multiple instances of adapters (based on one or
more adapters) to accommodate the varying needs of your IdP partners.
But I don't understand why the IdP connection requires a SP adapter? Why is it required and what does it really do?
In my use case I use PingFederate as an OAuth server and authenticates the users via SP-initiated SSO to external IDPs and then in the OAuth Attribute Mapping of the connection I map the Assertion attributes directly into the persistent grant. Why does not this suffice, I dont understand the need for the SP adapter? How and who is intended to reference the adapter more that the IdP connection itself?
You're absolutely right, in some cases (like yours) an SP adapter is unnecessary.
Under your IdP Connection, under Browser SSO > User-Session Creation > Identity Mapping there is an option for "No Mapping" which will avoid having to map into an SP adapter. For more details see: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=uql1564003010611.html
The "No Mapping" option was introduced in PingFederate 8.1, so if you're on an earlier release it may not be available. In that case a "dummy" SP adapter should be mapped into your connection (even though it may not be used).
I have a question regarding the Attribute Contract configuration of an OpenToken Adapter for an IdP Server. As I was trying out the sample applications, it already has a config provided with it. Now that I'm trying to configure it without using data.zip, I'm having problems.
As I was trying to create a new adapter, the core contract subject shows up automatically. I have no idea what are the default attributes included in this contract.
Question: How will I edit what are the contents of this contract? Will my IdP Application handle it?
subject is the core contract, because that is what will carry the identity of the user, and is therefore the "minimum" - it must be returned (hence, "core"). Extended attributes can be added at the adapter, as long as the authentication method (such as a custom login page that retrieves attributes from a DB or something similar) can populate them into the token.
You may wish to review the documentation of the OpenToken Adapter.
Within PingFederate, the IdP Adapters are essentially Authentication plug-ins. There are many different types of IdP Adapters, whether it be the IWA IdP Adapter, HTML Form IdP Adapter, or the OpenToken IdP Adapter. The main use of the OpenToken adapter is to create a custom authentication plug-in that is an application you would implement. This is normally done for organizations that have very custom requirements for authentication that the out-of-the-box HTML Form Adapter or IWA Adapter cannot meet. The PingFederate sample applications for IdP show how to implement the interface.
When you use the OpenToken adapter, it is a secure interface between the PingFederate IdP Server and a custom application using the OpenToken specification. The custom application can be written in Java, .NET, or PHP and integrate using the OpenToken agent for the target programming language. As Andrew stated above, that custom application could query for attributes beyond simple authentication of the subject. Then within the application when the OpenToken is being generated you would need to insert the additional fields into the OpenToken. Then in the OpenToken Adapter hosted on the PingFederate you would need to configure the extended attributes using the matching syntax so that they could be used.
I have an ASP.NET application which uses login cookies already. I need to provide a link in my application upon clicking which the user should be able to access their info in SalesForce.com using SSO. I'm planning to implement this link as an ASP page that constructs a SAML assertion with the corresponding username in SalesForce.com, posts the SAML assertion to SalesForce.com SAML Endpoint URL, receives the SAML response from SalesForce.com and redirects the user to the session URL contained in the response.
Has anyone tried this approach instead of using a dedicated SSO server (such as OpenAM) ? Are there any issues in this approach ?
You won't be able to do that, because it would require you to implement most of SAML IdP (identity provider) piece on your own.
SAML is a complex standard involving multiple interactions between IdP and SP (service provider), it is so much more than just sending an assertion.
To enable SAML you'll need to install IdP (like OpenAM), connect it to your user database and to convert your application to SP.
Wikipedia has more detail on SAML iteractions.