I want to deploy 2 Web Applications and 1 IDP.
I call SP1, SP2 and IDP.
I look on agentless kit example
when SP1 need login, it wil redirect to /sp/startSSO.ping?PartnerIdpId=PF-DEMO and PF will redirect to IDP
When I finish login IDP will redirect to /idp/startSSO.ping?PartnerSpId=PF-DEMO
PF will redirect back to SP by lookup URL from [Application Integration Settings -> Default URLs]
If request come from SP2 how to mapping URL to redirect back to SP2?
How IDP know what request come from which SP?
I'm not sure exactly what stumbling block you are having or what version of PingFederate you're using, but in 7.1 that was released late-2013 there was a Default SP URL setting introduced at the IdP Connection layer (that overrides the global one you're referencing) that might help.
Details in the following section of the PF documentation:
https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FserviceProviderSsoConfiguration.html
https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FconfiguringDefaultTargetUrlOptional.html
(Release notes from 7.1 release: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=releaseNotes/PingFederate_7.1_-_August_2013.html)
Edit: Additionally, you might not be setting the RelayState value with the target URL (SP) you're trying to send the user to. For example, if you're doing IdP Init SSO, PingFederate as the IdP can set this value in the TargetResource parameter. For details, see: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FidpEndpoints.html
Related
I am working to understand the SAML request process using PingFederate.
I am making the SAML RST request in order to gain access to a SharePoint Online instance. PingFederate SSO is successfully set up and users must login through ping in order to get to sharepoint online.
Now I want to make a Saml RST to PingFederate STS using the Java STS SDK 1.1.
I have a working STS endpoint: https://my.ping.endpoint/sp/sts.wst
And my SharepointOnline endpoint is: https://mydomain.sharepoint.com
I am trying to figure out what to use as AppliesTo in this scenario.
Definition:
The Relying Party realm the token is to be issued for.
I've tried setting it to anything we can think of. But no luck. I was fairly sure I could use: https://tenantname.sharepoint.com/_forms/default.aspx?wa=wsignin1.0 but it didn't work. I keep getting a SOAP Fault from ping STS:
Unable to determine partner SP connection by AppliesTo: http://my-AppliesTo-url-here
Is this some URL I need to get from the PingFederate admin UI? How can I find this?
Under your "SP Connection", "WS-Trust STS", "Protocol Settings" there is a place to enter the "PARTNER SERVICE IDENTIFIER (CORRESPONDS TO APPLIESTO IN RST)"
Im trying to configure ADFS to work as a Claim Provider (I suppose AD will be the identity provider in this case).
Just for simple testing, ive tried the following on windows server 2016 machine:
1) Setup AD and domain = t1.testdom (Its working cause im actually able to login with the domain)
2) Setup DNS. Added a host (A) for adfs as fs.t1.testdom
3) selfsigned certificate (https://technet.microsoft.com/library/hh848633):
powershell> New-SelfSignedCertificate -DnsName "*.t1.testdom"
4) created a dedicated service account for gMSA
5) setup ADFS.
Server name set as fs.t1.testdom
service>authentication method is enabled as form authentication
6) Also fixed the SPN via powershell to make sure all needed SPNs are there and given to the right user account and that no duplicates are found
--
However, when I try to access the login page on browser via https://fs.t1.testdom/adfs/ls I get the error. The log on server manager says the following:
`There are no registered protocol handlers on path /adfs/ls to process the incoming request`
So is there a way to reach at least the login screen? So I can move on to the next error.
this is what I get on the /ls screen:
Finally found the solution after a week of google, tries, server rebuilds etc!
(This guru answered it in a blink and no one knew it!
https://www.experts-exchange.com/questions/28994182/ADFS-Passive-Request-There-are-no-registered-protocol-handlers.html)
The IdP-Initiated SSO page (https://fs.t1.testdom/adfs/ls/idpinitiatedsignon.aspx). Note that if you are using Server 2016, this endpoint is disabled by default and you need to enable it first via the AD FS console or
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
--
My question is, if this endpoint is disabled, why isnt it listed in the endpoints section of ADFS Management console?!!
We are using PingFederate as Service Provider and are using Opentokenadapter.
We are also using mod_pf apache library provided by PingFederate.
Is there any way we can configure "Logout Service (present in OpenToken Adapter )" in the mod_pf configuration? Is there any query parameter for it just like we have for PartnerIdpId, TargetResource etc?
The Apache Integration Kit's mod_pf.conf refers to the /sp/startSLO.ping application endpoint. In that configuration file is where you will configure various bits for the integration... You can review the /sp/startSLO.ping options as listed here:
https://documentation.pingidentity.com/pingfederate/pf81/index.shtml#concept_spServices.html#concept_spServices
The "Logout Service", as defined in the adapter, is where the browser will be sent to for an SLO that will destroy any current session within the SP Application. By spec, that application must return BACK to PingFederate, so that PingFederate can respond back to the IdP with a success/fail. If you plan to support SLO, then this "service" must exist. It's "goal" will be close the session, and redirect back to PingFederate with a success.
Ok, i'm integrating simpleSAML with symfony as an sp, for my own reasons I don't want to use the sp bundle.
I've setup simplesaml in /simplesaml, as per instructions, and it works a charm.
I'm able to test it with a simple web site test.php, where i do this
$as = new SimpleSAML_Auth_Simple('google');
if($as->isAuthenticated()===false){
$as->requireAuth();
}
$attributes = $as->getAttributes();
print_r($attributes);
and that works fine, but if i flip it over to my symfony site, i can see symfony resetting the php session cookie, so i assume that it is not able to find the one set by simplesaml.
I tried the same above code in my logincontroller to see if i could get my idp supplied data, i can not, it bounces me through my IDP login and lands me on the simplesaml page, which gives me 'State information lost'
Any help appreciated.
'State information lost' is pretty generic. The documentation provides a check list of things that can cause the problem
Hostname changes. If you visit https://www.example.com and your metadata says https://example.com then the cookie created on the initial visit won't be available.
Move between HTTPS and HTTP.
Mismatch between the cookie settings (name, path, domain, etc) for SSP and symfony
The SamlTracer plugin for firefox is useful in deciphering what SAML messages are being exchanged, including what attributes the IdP is sending.
OpenAM version -12 , Agent version 3.5 and 3.3 , tomcat version 7
I have tried to follow the link https://forums.alfresco.com/forum/installation-upgrades-configuration-integration/authentication-ldap-sso/sso-openam-06052012 to set up my J2EE Agent. Let me paste the steps after asking the question(see at the end)
but I am getting the error as asked below
Not able to configure J2ee agent on adding my customized data store for users
I have tried to use 3.5 version installed and uninstalled multiple times and tried previous version.
There is a nice discussion on this topic at http://database.developer-works.com/article/16009911/%22Cannot+obtain+Application+SSO+token%22+error
but it did not help me much.
I am using LDAP so I have used LDAP realm and subjects are showing up ok. Also I am observing that the policy tab has changed quite a bit from how it is described in the Blogs.
Now with the roadblock I am not sure how to proceed as the error is not giving me any clue what to do. I even added the file named AMConfig.properties in the classpath with username and password of the agent and tried the username and password of the OpenAM admin too as suggested in the discussion mentioned. but that too did not help.
The issue is the Tomcat now is not starting and giving error that AMConfig.properties properties are needed
I know the OpenAM Realm setup is good as I am able to login via this realm to another application (Liferay) where I just have to give the URL for use OpenAM integration. but after uninstallation of the agent the tomcat starts without any error and i am able to login to the application
-------------------Step copied from 1st link(modified)--------------------------
1. Configure your OpenAM agent (tried both 3.5 and 3.3 version on tomcat 7)
a. Log into OpenAM as the admin user and navigate to "Access Control -> (Your Realm) - where in my case LDAP Realm (other application using it without issue)
b. Select Policies -> New Policy
c. Enter Share as the policy name and then create 2 new URL Policy agent rules
d. 1st Resource Name = http://:/share/*
e. 2nd Resource Name = http://alfresco.domain.com:8080/share/*?*
f. Add a subjects - already part of LDAP Realm
g. Now select Agents -> J2EE - > (your J2EE agent)
h. Select the Application tab
i. Login Processing -> Login Form URI - add /share/page/dologin
j. Logout Processing -> Application Logout URL - add Map Key = share - Corresponding Map Value = /share/page/dologout
k. Not Enforced URI Processing - Add 2 entries - /share and /share/
l. Profile Attributes Processing - Select HTTP_HEADER and add Map Key = uid - Corresponding Map Value = SsoUserHeader (This is what I called my header in the alfresco-global.properties file - see below)
Auth chain
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm
alfresco.authentication.allowGuestLogin=true
SSO settings
external.authentication.enabled=true
external.authentication.defaultAdministratorUserNames=admin
external.authentication.proxyUserName=
external.authentication.proxyHeader=SsoUserHeader
NOTE- It does not seem possible to configure SSO where the Guest login has been disabled. There are webscripts used on the Alfresco repository that need guest login.
That concludes the setup for Alfresco and OpenAM
For Share you need to have the following section uncommented in your share-config-custom.xml
alfresco/web-extension/alfresco-system.p12
pkcs12
alfresco-system
alfrescoCookie
Alfresco Connector
Connects to an Alfresco instance using cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
alfrescoHeader
Alfresco Connector
Connects to an Alfresco instance using header and cookie-based authentication
org.alfresco.web.site.servlet.SlingshotAlfrescoConnector
SsoUserHeader
alfresco
Alfresco - user access
Access to Alfresco Repository WebScripts that require user authentication
alfrescoHeader
http://alfreso.domain.com:8080/alfresco/wcs
user
true
Notice I am not using the SSL cert and in my alfrescoHeader connector I have used SsoUserHeader (as setup in OpenAM) and the endpoint uses the alfrescoHeader connector
Now you need to add the OpenAM filter to the Share web.xml file
Add the following filter just before the Share SSO authentication support filter
Agent
com.sun.identity.agents.filter.AmAgentFilter
Add the following filter mapping to the filter-mapping section
Agent
REQUEST
INCLUDE
FORWARD
ERROR
----- End ----------
The error message is a bit misleading: the Cannot obtain application SSO token in general means that the agent was unable to authenticate itself. When you install the agent, the agent asks for a profile name and a password file, those values need to correspond to the agent profile configured within OpenAM.
To test if you can authenticate as the user, you could simply try to authenticate as the agent by making the following request:
curl -d "username=profilename&password=password&uri=realm=/%26module=Application" http://aldaris.sch.bme.hu:8080/openam/identity/authenticate
In the above command the realm value needs to be the same as the value for the "com.sun.identity.agents.config.organization.name" property defined in OpenSSOAgentBootstrap.properties (under the agent's install directory).
Having bad username/password combination is only one of the possible root causes for this exception though. It is also possible that during startup the agent was unable to connect to OpenAM to authenticate itself. In those cases the problem could be:
network error, firewall issues preventing the agent from contacting OpenAM
SSL trust issues: agent's JVM does not trust the certificate of OpenAM's container (only problem if you've installed the agent by providing OpenAM's HTTPS URL and the certificate is self-signed or just simply not trusted by the JVM)