I have a situation, wherein, I have integrated, WSO2APIM, Identity Server, Microsoft ADFS2.0. Configured successfully so that MSADFS is acting as IdP, APIM acting as SP (with /publisher) as a service. Configuration worked fine when accessed(/publisher of APIM), ADFS presented LogonPage, all necessary SAML2.0 exchanges happened perfect and final page (/publisher) presented.
Now, the actual situation is, instead of accessing APIM service (/publisher), I need to access a POST Rest URL(Eg. APIMIP:Port/vendors/payments). This API is configured to hit backend API (Eg. BEIP:Port/vendors/payments).
1. In above situation, I need to pass the SAML authentication information or any other authorized info to actual BE, somehow.
2. How to achieve it.
Related
I have a query about how keycloak is supposed to be working with client without GUI access.
Basically I have:
A keycloak server configured with a realm, clients(Access type confidential) and Users
A server application with a GUI that also provide API, secure with keycloak (client, user, blablabla)
This is kind of working already as I am able to log on the GUI, have the redirect, etc..
Even accessing the APIs works well, when I have access to a GUI: I log on my UI, follow the redirect and get my UI to display the token. The the human (to differentiate the user from an application), can use the token in any API client.
In this context the user never sees the client secret, which is instinctively the right way. (note that I am very opened to people telling me my instinct is wrong!)
What I am NOT able to do so far is to find the way a server application (without GUI) can get a valid token?
The authorization_endpoint, as far as I understand it, requires both the client id and the client secret) to get a token, which I would rather avoid: I don't think giving my client secret to all my "customers" is the proper way to do it.
Alternatively I could create an API on my client that woudl ask for user credential and ask for the token in its behalf, but that would expose the clients credentials to my application, which is against the whole concept!
I tried setting my client Access type as public, but when I use the API call below I also get a error:
POST /auth/realms/realmname/protocol/openid-connect/tokenAPI
'grant_type=client_credentials'
'client_id=client_id'
'username=username'
'password=password'
{
"error": "unauthorized_client",
"error_description": "Public client not allowed to retrieve service account"
}
Would anyone know how this is supposed to be done ?
Thanks in advance.
Max
(...) A server application (without GUI) can get a valid token... typically using the Client Credentials flow.
But we would define in this case a dedicated Client for your server (client?) application to authenticate against. The returned token (not bound to a specific user) will serve for authorizations on allowed applications (i.e. your classic GUI or API clients).
So, basically you should (in very short):
define a specific confidential Client in your Keycloak
add the desired applications (or other Clients) to the Client Scope(s). Those you want to authorize transitively from this Client.
authenticate against this Client with Client Credentials flow (given the token endpoint, client id, credentials, scope)
ensure that you are authenticating through TLS and that parameters are included in request body (and not in headers - for enhanced privacy)
further harden security of your Client(s)
When you do not want anymore this particular server (client?) application to access your applications, you can change the corresponding "authentication" Client's secret/credentials or simply delete it.
"I don't think giving my client secret to all my "customers" is the proper way to do it."
You are right and the proposed method above strictly avoids that. Each customer would have its own credentials.
EDIT
(adding more details)
By performing as above, you would end up with the following scheme:
Flow Keycloak Server
C/S app. or Customer X <--- Client Creds ---> Auth. Client X
--- Access Token ---> Appl. Client <--> Appl. Server
C/S app. or Customer Y <--- Client Creds ---> Auth. Client Y
--- Access Token ---> Appl. Client <--> Appl. Server
Browser users <--- Standard ------> Appl. Client <--> Appl. Server
Note: this is not a detailed flow chart. Arrows mostly show relationships here.
Finally, please note that the terminology may differ a little here, but the proposed method is basically the same that Google uses. So you may aswell take some inpiration from there:
https://developers.google.com/identity/protocols/oauth2
I just had the same problem some weeks ago
In my case, I have a backend API and a frontend application that the users can use.
Eventually, I can't share the client_secret to the frontend application.
So here is my solution:
On keycloak, create a client (ex front_end_client) with grant type public
This client is going to be used by the frontend application to authenticate users using implicit flow (with PKCE will be more secure)
On keycloak, create a second client (On the same REALM as the first client) with grant type confidential, this client is going to be used by the backend API
Now, this is how it works:
Frontend app authenticate users and get the access token (Using the font_end_client)
The frontend app sends this token for every request to the backend
Backend app verify this token, and can retrieve permissions from it
We are using Apigee as our Authorization Server (AS) and we have a few Spring Restful services deployed in IBM Bluemix public cloud which acts as our Resource server (RS).
Each of the services has an equivalent proxy service configured in Apigee. For the proxy services, we have configured the VerifyOAuthTokens policy to verify the token passed by the user and return an error if invalid token is passed
The problem is, since our RS is in the public cloud (no plans or need of moving to a dedicated or private cloud) the api endpoints are open and can be invoked by anyone who knows the url.Though the expectation is everyone should call the apis via APIGEE proxies but we cannot force that since we are in public cloud and there are no options of opening ports coming from apigee or something. We would like to take the following approach to secure the api endpoints.
Accept the Authorization header for each call
Take the token and call a validate token service in Apigee
For 2, We are not able to find an APIGEE api which can validate an access token similar to say googles
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
or Github's
GET /applications/:client_id/tokens/:access_token
Is there actually an external APIGEE service to validate a token?
If not, what would be the best way to make sure that only valid users with valid tokens can access the apis?
Thanks,
Tatha
Did you look at this post in the Apigee Community: Using third-party OAuth tokens
We did something similar to this but not using oauth tokens. We used Apigee to do a callout to a third party IDP (identity provider). The 3rd party IDP wasn't able to generate tokens but exposed a web service to authenticate the user. If the user was authenticated successfully (based on interpreting the result received back from the target endpoint webservice), then you tell Apigee that it was successful by setting the external authorization status to true (step #2 in the link).
NOTE: this has to be done inside an Assign Message Policy step PRIOR to the GenerateAccess token operation. Apigee interprets this as a successful authorization and then can generate a valid oauth token that the caller can then send along to access the protected API.
Am searching for Desktop application manage Enterprise
Single Sign On
(SAML v2, Identity Provider , Service Provider )
Here is how i achieved in my enterprise:
There could be 2 approaches
Use "windows authentication" which can give you actual user trying to access website. Any enterprise application ( assuming it being hosted on Intranet) has integration to Active Directory. This User identity can be authenticated using LDAP server
Use OAuth way and use Third party which provide Identity management. Front End calls their services to generate token. This token can be sent to backend which will authenticate this token against the validator service.
I have used ADFS 2.0 as RSTS for SSO where in we have all the IdentityProviders and the Relying parties are configured. You can use the active end point of the STS (in case you want to authenticate against external sources like web api/ web service/ AD/ Database then prefer writing you own custom STS as the IDP).
Firstly you will get the boot strap token from the IDP and then get the Relying party token from the RSTS. In both the calls you need to communicate against the active end point (a wcf end point which implements WS Trust protocol).
Passive end points/ passive calls are used for thin clients.
You can try using ADFS 3.0 which even supports JOT (JSON) tokens (a very light weight token) along with SAML 2.0.
I am using WSO2 5.1 – STS service. With the stsclient (java program) I am making a SAML token request. However, I am not getting the claims details as part of the SAML token response from IS.
The same request is returning the claims when a request is sent to WSO2 IS 5.0.
For SSO requirement Looks like I have to set “Attribute Consuming Service Index”. But not sure where to set this attribute in the SAML request while using the stsclient java program.
This resembles this question but not related to STS.
In your Service Provider's SAML configuration, you have to make sure following two checkboxes are checked.
Enable Attribute Profile
Include Attributes in the Response Always
Then, inside the Claim Configuration section of the Service Provider, you have to add the particular user claims that you wish to receive in SAML response as the Requested Claims.
Then you should be able to receive the user claims in SAML response, provided that user's profile already contains values for these claims.
Refer [1] for more details.
[1] http://tharindue.blogspot.com/2016/08/retrieving-user-claims-in-saml-response.html
I am trying to configure openam as Identity provider to test my SAML
based service provider application.
I have searched a lot and saw documentation of openam. There are lots
of thing supported by openam which probably I do not need at this
moment. I don't wish to read whole documentation which will take lot
of time reading things I do not want to test right now. I even saw
chatpet 9 "Managing SAML 2.0 SSO" at
http://docs.forgerock.org/en/openam/10.0.0/admin-guide/index/index.html
But it requires lot of things to be configured before this.
Is there any quick start guide to test it as saml based IdP?
EDIT
Not a quick, detailed is also fine. But I want OpenAm as Identity provider. SP is an application hosted on Jetty which we have developed. Also tell me what changed do I have to make on SP like what urls of application should respond with what.
There is no one-fits-all answer to your question really. Setting up SAMLv2 Federation largely depends on the actual SP implementation, some SPs can work with SAML metadata, some don't..
The simplest way to set up federation between two OpenAM instances for reference would be something like:
Create Hosted IdP wizard on node1
Create Hosted SP wizard on node2
On both nodes remove the persistent NameID-Format, so both will have transient at the top of the list
Register Remote SP wizard on node1, with URL: node2/openam/saml2/jsp/exportmetadata.jsp
Register Remote IdP wizard on node2, with URL: node1/openam/saml2/jsp/exportmetadata.jsp
On node2 in the Hosted SP setting set the transient user to "anonymous"
After all this you can test Federation by using:
/openam/spssoinit?metaAlias=/sp&idpEntityID=node1_entityid on node2
/openam/idpssoinit?metaAlias=/idp&spEntityID=node2_entityid on node1
I've used the default metaAlias values, but those should be visible on the console pages. Similarly by downloading the metadata you can see the actual entity IDs for the given entities.
Based on this, you should see now that with an OpenAM IdP you could at least test SAML support using the idpssoinit URL (if your SP supports unsolicited responses), but from the other way around it pretty much depends on your SP implementation how you need to actually trigger a SAML authentication.
This seems like a simple setup.