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).
Related
Current State: BizTalk receive message via Web Service A (hosted on the same machine). BizTalk process the message and send it to backend.
Future State: BizTalk still receive message via Web Service A. If a field inside the message matches a certain value, BizTalk needs to send the message to a different web service (Web Service) on another server. Else, proceed with existing flow.
BizTalk is required as a middleware between Application and Web Service B due to network connection. Server for Web Service B only accept TLS1.2 which Application Server yet to support.
Is it possible to reroute the message even before it enter the first orchestration?
Kindly provide best way to do it with detail guidance on changes required or point to existing question or documentation if any.
p/s: Newbie to BizTalk. Let me know if further information need to be provided.
Yes, quite possible
Promote the field that you wish to route on in the schema
Set the filter expressions on the send ports that look at this promoted property
Note: For TLS 1.2 you will need a Custom End Point behaviour on the send port to specify to use TLS 1.2.
As #Dijkgraaf says, you can use Promote field on the schema and then use filter expressions on the send ports to redirect the incoming message to the new Web Service B.
If you need an Orchestration to implement some process before send to the Web Service B, you can use Filter Expression property of the first Receive Shape, to catch the messages with the Promoted Property value that you need.
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'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.
We run a Shibboleth Identity Provider, and have been increasingly asked to integrate with applications using non-Shibboleth SAML solutions, and encountering difficulty with regard to attribute naming. With a pure Shibboleth IdP & SP relationship, I know that the IdP can release user attributes to the Service Provider using arbitrary attribute names in the assertion. The Service Provider, having been configured to receive specific attributes using the IdP-provided names, re-maps the attributes from the IdP into attribute names useful to the Service Provider, using a configuration in the attribute-map.xml file.
My problem is with non-Shibboleth Service Provider operators, many of whom have refused to re-map attributes sent from the IdP, instead demanding new attributes be defined on the IdP (to carry values already available in existing attributes), using names dictated by the Service Provider owner. This causes the user's attribute object on the IdP to grow unnecessarily (at the time of authentication), because all defined attributes are populated with values first, and then they are filtered down to only those attributes approved for release to the requesting SP.
Is the attribute mapping feature, present in the Shibboleth Service Provider, part of the SAML/SAML 2.0 specification/standard, or is it a feature introduced by the Shibboleth developers? If it's part of the standard relationship/behavior in a SAML solution, can someone direct me to the authoritative standards document?
I've read through what I can find on OASIS regarding SAML standards, but I can't find anything regarding this behavior.
Attribute mapping is an application specific bit of functionality.
The SAML specification(s) details with things like message exchanges and XML schemas, not the functionality software should provide or how bi-lateral arrangements between IdPs and SPs should be organised. They have nothing to do with the SAML specification. Sorry.
Note that there are plenty of other SAML products that provide similar attribute mapping functionality, it's not just shibboleth that does so. I imagine the problem here is that the Service providers consider their requirements more important than yours and aren't prepared to make an exception. Either that or they don't know how.
I'm using WCF services ensuring that UserName/Password must be provided for each request. I need use same service from many clients, but I need impersonate the call to access the appropriate resources for each client. When I call the service directly from the client there is no problem, because I use for each client a pair UserName/Password defined in theirs web.config. The problem came when I need to call a second Web service from a call to the first-one using the same identity. This second Web service requires UserName/Password, but I only know who is the caller (UserName) but not the password.
How I can impersonate this second call without knowing the password for the corresponding username?
EDIT: The app (Web App and Services) is running in a shared hosting environment where I can't use Windows Authentication to configure Kerberos for Delegation. I have defined a UserNameValidator to process on each call the pair UserName/Password against a custom SQLServer database. Moreover, the intended customers of this app will use it from Internet, without requiring a windows account, that is because I need a more flexible, SQL-based, authentication schema.
You need to look at using Kerberos to handle the passing of authentication onwards to other services from your first WCF service.
Have you taken a look at the declarative security options? The linked article by Juval Lowy includes an internet application scenario as well.