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?
Related
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.
I'm using the Google client API library for Python. My code is running on an Ubuntu 14.04LTS server.
I have a working Google Compute project, were I created and downloaded a OAuth2.0 token to my server.
I'm trying to write a script that does the following:
Automatically (with no user interaction) authenticate to Google Compute engine.
create a new VM and then perform more actions...
My basic problem is using the OAuth2.0 authentication. It required user approval on a javascript supporting browser, and I want to do it automatically, on my server.
Using my code on my desktop works. A browser page pops up requiring my approval. On my server, I get the following message:
we have detected that your javascript is disabled in your browser
The code segment I use for authentication is:
# authenticate using the OAuth token
client_secret = os.path.join(
os.path.dirname(__file__),
self._oauth_token_path)
# set up a Flow object for the authentication
flow = client.flow_from_clientsecrets(
client_secret,
scope=scope,
message=tools.message_if_missing(client_secret))
# open credential storage path
credential_storage = file.Storage(self._credential_storage_path)
credentials = credential_storage.get()
# get credentails if necessary
if credentials is None or credentials.invalid:
credentials = tools.run_flow(flow, credential_storage, flags)
I read about service account access as a replacement of the regular OAuth2.0 authentication. Does any one know if that's the best way to go? any thoughts on how to do it better?
OAuth 2.0 requires user approval and is not the method to go for if you want to run your code/scripts automatically.
Service accounts are more suitable for this and are supported by the API (https://cloud.google.com/compute/docs/authentication#tools)
You create a service account + key in the developer console and use both to authenticate your application.
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