I did SP initiated SSO for SalesForce and OpenAM successfully.
In SalesForce SSO setting I used Identity Provider Login URL : http://localhost:8080/opensso/SSOPOST/metaAlias/idp
This URL accept SAML request and created SAML Assertion for SalesForce with IDP default login authentication.
Instead of above URL I when I use my Custom Authentication Module URL.
It does:
It redirect to IDP with custom authentication
Does the authentication and display IDP home page.
It won’t show SalesForce home page.
I checked debug log it is not creating SAML assertion for SalesForce.
Is it possible to create SAML assertion from IDP?
Or should custom authentication module has to take care to create SAML assertion?
Don't change the URL in the Salesforce SSO settings - that needs to remain http://localhost:8080/opensso/SSOPOST/metaAlias/idp in order to do SAML. Instead, in the extended metadata for the identity provider, you should set AuthUrl to your custom auth module URL - e.g. http://localhost:8080/opensso/UI/Login?module=CustomAuth.
This document at Oracle describes a similar configuration http://docs.oracle.com/cd/E19575-01/820-4729/ggxft/index.html
Related
When using phpCAS to authenticate users in a CAS server the application redirecs the user to CAS for authentication using a url like:
https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice
So the question is what service url (application url) the library uses by default, and how can we change it?
I have installed CAS6.4 and CAS Management .
I am able to access https://CNNAME/cas/login & it successfully login .
I could also Login to https://hostanme/cas-management/ and it redirect back to cas management.
I have added service URL in cas management as below :
^(http|https)://CNNAME*/**
http*://hostname2/*
But when i access these URL, i get error as
Application Not Authorized to Use CAS
The application you attempted to authenticate to is not authorized to use CAS. This usually indicates that the application is not registered with CAS, or its authorization policy defined in its registration record prevents it from leveraging CAS functionality, or it's malformed and unrecognized by CAS. Contact your CAS administrator to learn how you might register and integrate your application with CAS.
In the logs i get error as :
2021-03-01 07:15:39,111 WARN [org.apereo.cas.services.RegisteredServiceAccessStrategyUtils] - <Unauthorized Service Access. Service [https://hostanme/callback] is not found in service registry.>
I have been struggling to get this solved for for days, could someone please help me with this.
According to the CAS Webflow (https://apereo.github.io/cas/5.0.x/images/cas_flow_diagram.png):
After successful authentication the CAS server sends a redirect to the browser that contains a Cookie and a URL (Location-Header). This URL appears to be the originally requested protected URL with the addition of a ticket Parameter (containing the Service Ticket). Is it a violation of the CAS protocol if the CAS server adds more parameters to this URL?
In my actual case the user selects a language from a dropdown, when authenticating at the CAS server. This lang-Parameter is then submitted along with username and password and the CAS server simply appends it to the URL he sends in the redirect as something like "&lang=fr-FR".
The Apereo Java client runs into a validation failure because of that parameter. This is because the Service URL to validate the Service Ticket for contains this lang parameter. The CAS server then does not validate the Service Ticket, because it was issued for a different URL (without lang parameter).
So my question is: does this particular CAS Server violate the CAS protocol?
Or would the Apereo CAS client be expected to deal with this by stripping off all unknown request parameters when constructing the Service URL for validation?
So my question is: does this particular CAS Server violate the CAS protocol?
Yes.
From the CAS Protocol, service for the login endpoint is:
service [OPTIONAL] - the URL of the application the client is trying to access.
From the CAS Protocol, service for the validation endpoint is:
service [REQUIRED] - the identifier of the service for which the ticket was issued
Also specified under error codes,
INVALID_SERVICE - the ticket provided was valid, but the service specified did not match the service associated with the ticket. CAS MUST invalidate the ticket and disallow future validation of that same ticket.
I'm attempting to understand how spring boot uses http sessions to manage the oauth authorization code flow.
I understand that after the user submits their credentials via the /login form spring will persist the authentication object so it can be retrieved when the browser is redirected to retrieve the authorization code.
What I dont understand is if the browser needs to sends jsession cookie to the server or http basic authentication header when invoking this flow.
For example if I wanted to initiate the flow manually via curl do I need to specify any special headers ?
It doesn't use HTTP sessions to persist it, the client ID and authorisation code (the code that's passed back to the client app after the user authenticates) is used to identify the authentication object. The authorisation code is then used to obtain the access token.
So:
The client app redirects to the auth server, passing in their client ID.
The user authenticates with their username and password on the auth server , which stores the authentication against the code and client ID and passed the authorisation code back to the calling app as a request param on the redirect URL.
The client app calls back to the auth server, authenticating with it's client ID and secret and passing in the authorisation code. This is then swapped for the access (and possible refresh) token.
If the app needs the user details, the client app calls the user details endpoint authenticating with the access token it now has.
So I've set up ping federate as my IDP and connected it to my data store. But when I go to my entity url or my home url, I get a 404...
I've verified the port is listening.
Best way to test HTML Form IdP Adapter is to configure an SP Connector. If you are just setting up the server, the most simple method is to just map the HTML Form as an IdP Adapter in the SP Connection configuration. Another key to a simple configuration for the SP Connection is to setup an ACS URL to something like https://posttestserver.com/post.php (POST). This is a cloud site that will receive the SAML assertion and you can view it. Once the SP Connector is configured, copy the IdP-Initiated SSO URL from the configuration and put that into the web browser.