I have WSO2 Identity Server set up together with a web application that is configured for SAML 2.0 SSO.
When a user has authenticated, I want to invoke a SOAP service from this application. The SOAP service trusts the Identity Server and is protected with WS-Security. It expects a SAML 2.0 token in the request.
Is it possible for the application to get a SAML token from the WSO2 STS for the currently logged-in user?
The STS seems to require username/password (or X.509 certificate) to authenticate the user, which I don't have in the application (I have only the username).
Is there another way apart from the STS to get a token for the logged-in user?
Related
I have created identity provider and from browser it's working fine.
Reference : Keycloak Identity provider post-broker-login throwing error
From browser I can do login with external IDP and if the external IDP user is not there in keycloak it gets created in the keyclock that is absolutely fine and redirect to dashboard.
But my question is how can we do this flow with keycloak rest api?
Is there any api for to login with external IDP and will get the token of external IDP as well as token of keycloak?
For the typical user authentication use-case, ideally the user would simply get redirected to the Keycloak login page of your realm, would click on the external IDP, and proceed with the authentication process.
But my question is how can we do this flow with keycloak rest api?
Via the Keycloak Rest API I do not think you can perform this exact flow, at least not out-of-the-box.
Is there any api for to login with external IDP and will get the token
of external IDP as well as token of keycloak?
You can use the Keycloak's Direct Access Grand flow (aka Resource Owner Password Credentials Grant in terms of OAuth2 specification), exchange the user's credentials for a token from the External IDP. Afterwards, you can then perform an external-to-internal token exchange of the token from the external IDP for a token from your internal Keycloak realm.
Bear in mind, however, that some might consider this approach has not being a good practice, read more about it in this stack overflow thread.
I have the following:
An existing WEB application using SAML for authentication. Using B2C custom
policies, I have successfully set up Azure AD B2C to allow this
application to authenticate users using SAML.
An API (ASP.NET Web API) using OpenID connect to authenticate callers (on the same Azure AD B2C).
I would like to authenticate calls from the Web Application to the WebAPI using the identity of the Web application authenticated user.
So I have would need a JWT token so I can validate it in my API middleware.
Is there any simple way of converting the SAML Assertion to a JWT token so the Web application can send it to my API with requests ?
I have read somewhere that IdentityServer could do the job using Azure ACS (For AAD B2C ?) but I understand that ACS will be retired on November...
Thanks.
You can ask your IDP to provide the JWT token as a SAML attribute inside your current SAML tokens, or ask them to provide you with an alternative way of acquiring the JWT tokens you require.
Also, you can configure IdentityServer to return JWT. Go to global config and change the default token type to JWT (same value as the default http token type).
I have a domino server (v9) with SAML Login enabled through Oracle OpenSSO (and simple login methods disabled, like Basic or Forms).
I can log onto the server using a browser, which does multiple redirects, form submits and so on, to push the SAML token from the Identity Provider to the names.nsf, which then creates a LTPAToken based on the SAML token.
However, I have to access some URLs (API endpoints) programmatically, which are secured by this SAML Login. Does names.nsf allow any API-friendly means of authentication (like Bearer Token) instead, and does OpenSSO support them as well?
I don't know Domino, but for OpenSSO I can say that it embeds a STS (Security Token Service). That means you can request it a SAML Bearer Token.
https://docs.oracle.com/cd/E17842_01/doc.1111/e17844/concepts.htm
I have a external openidconnect identity provider registered with Keycloak. When the client app tries to access the protected resource it gets redirected to KeyCloak login page. On the login page I have the external openidconnect provider buttons enabled. Once the user clicks on the button he is taken to the external identity provider (which is identityserver3 instance). The external provider does authenticate the user and send back a code.
Now the redirecturl for the registered client in the external identity provider is that of keycloak's. So after authentication is successful at the external IDP it send back the code(because it is Auth code flow) to keycloak at a redirect url:
http://localhost:5555/auth/realms/QA/broker/keycloak-client/endpoint?code=7bcf5157105199d50874e64eabf03858&state=wQhNIEKW0Ws6CotZg2EsvOorjDVQlWVvobcM2skPSXo.keycloak-client&session_state=rhgu-BXT8FniG9Z-UARKpp_f-V1nLN-VxFmSE3PSxDg.99b2d903367208e4261fefa475afb1eb
In the URL if you see it ends with endpoint. I don't think that's correct but I cannot change it in KeyCloak (it's disabled) and because of that in the external IDP client configuration.
KeyCloak does not understand above url and errors out with a message "unexpected error when authenticating with Identity Provider"
Isn't KeyCloak supposed to understand the code flow and make another request for token after receiving the code. Then the external IDP will respond with token and Keycloak will send back that token to client(will also store it for future use).
Can someone please share some knowledge on how Keycloak works with external openidconnect ID provider with code flow.
Usually the redirect URI for external identity providers take the form of {keycloak-host}/auth/realms/{realm}/broker/{provider}/endpoint. You have to specify this as the redirect URI when you register your client in the external identity provider. Once the user is authenticated through the external IdP, authorization code will be sent to this url, which in turn will redirect it to the redirect url of your client application (specified when registering the client in Keycloak).
Unexpected error when authenticating with Identity Provider is the general error message sent by Keycloak for several errors that occur during the OAuth flow. You won't be able to determine the actual cause without going through the stack trace or the logs in the prompt.
You are getting this error because keyclaok is unable to get token from identityserver3 by exchanging authorization code. Where did you hosted identityserver3? Does it have a real ca certificate or you are using self sign certificate? Have you configured client_id , secret, token endpoint properly in keycloak external IDP configuration? You can test manually my posting client_id, secret, code (that you received) in token endpoint of identityserver3.
I have a client application (windows) which the user is logged into. From this application, the user will want to access a remote website using single sign-on (SAML) and will be authenticated by Microsoft WIF. To do this the user, will click a button which opens a local web browser, generates a SAML token (containing username and roles, etc) and makes a HTTP POST to a remote website to access it, signing them in.
I want the user to be signed-in automatically, based on their credentials from the windows application.
I know roughly how to generate the SAML token, but presume this requires the signing certificate to be installed on the local PC, which would need to be installed into all PCs in my Company.
Installing this certificate doesn't seem quite right. How else can I safely allow users to generate a SAML token which will be accepted by the Service Provider (via single sign-on)?
UPDATE:
The user is not authenticated into the Windows Application using Windows Authentication (Kerberos), we make a custom SQL call to a database of username/password.
In the win app, we will know the username and their roles, so could generate claims from this, or pass it to a remote STS to generate and sign the SAML token. But again passing this data across to the STS seems totally wrong again.
The signing certificate must not be on the user desktop. Otherwise, any user could potentially generate a SAML token with the userid it wants.
What you want is a Secure Token Service (STS): an identity provider that will authenticate your user through Kerberos (as you want to re-use the identity of the logged-on user) and give you a signed SAML token.
All of this could be done when you open a web view in your application. The starting url should be the Identity Provider endpoint for IDP-initiated SSO, with a url parameter identifying the service you want to access.