How does OIDC based SSO works? Is it recommended to store OIDC token on browser? Is it safe enough? If OIDC token is stored at server side, how to pass this when browser redirection happens in order to access other SPA application?
The article "Identity Federation by OpenID Connect" explains how OIDC-based SSO works.
Related
We have an MVC application (<myapp.somedomain.com>) .net 4.5.2 (OWIN/ADAL) that uses ADFS2016 for AuthN/AuthZ via OIDC/OAuth2. Users' credentials and attributes are stored in AD LDS. A client (X) requested to authenticate in the application via their IdP over SAML2. Is this possible WITHOUT making changes to the application?
The flow I am looking for; for this client the app’s URL would be (<myapp.somedomain.com/?client=x>). Our ADFS would recognize and redirect the client to their IdP where they would authenticate and than they would be send back to our ADFS along with some predefined claims. Our ADFS would map these claims to an Id Token / Access Token for our application to use. Am I dreaming or is this indeed feasible?
Any links to articles / documentation on how this could be achieved would be most helpful.
As #Wiktor suggests, you could add a SAML client-side stack to your app.
The other way is to federate ADFS with the SAML IDP.
When the user is redirected to ADFS, they use Home Realm Discovery to either redirect to the SAML IDP or authenticate on ADFS directly.
ADFS should handle the token conversions but you may have to fiddle around with the claims rules.
Just started POCing KeyCloak to hook up LDAP for user federation (really easy!) and set up a SAML Service Provider with Node.JS (took a bit more time to get the config right). See POC
Question:
Using KeyCloak as the sole Identity Provider, is it possible to set up a 3rd party service (Appian) as a SAML Service Provider, and use the SAML Username and/or Token(session_index) it receives to request an OAuth Token?
Preferably the 3rd party (trusted) service, behind the scenes, would make the OAuth request (with a client id?) to get an access token, and use the token to make API calls.
Seems like there could be two KeyCloak clients, one for SAML, one for OAuth, but then KeyCloak would be able to coordinate the auth under the covers.
You can exchange a SAML assertion (NOT its decoded contents) for an oAuth access token. This flow is described in RFC 7522 (SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants). In practice, this is an exotic use case and it's hard to implement. It assumes that the requester (client) has a way to acquire a SAML response from the IdP and wield it to grab an oAuth access token. To top it off, there are precious few IdPs that support RFC 7522 exchange. At the moment, Keycloak does not support it.
A more straightforward variation of the use case you're thinking about is an ability of a client to request any token (SAML, oAuth, ...) from an identity provider/authorization service without reauthenticating. This is possible with some providers but these mechanisms are proprietary to each provider. For example, Salesforce Identity service allows various tokens to be obtained if you send a request with a Salesforce session ID in a specific format.
I keep hearing OpenID is for federated authentication where as OAuth is for delegated authorization. Is OpenID just the initial step of OAuth involving a redirect to the identity server ? If so why cannot I use OAuth for authentication ?
Open id and Oauth are two different things.
OpenID is about authentication (ie. proving who you are), OAuth is about authorization (ex. I grant your application access to my Google drive account. When your application is accessing my drive account there is no guarantee that it is me preforming the action.).
OAuth is often used in external sites to allow access to protected data without them having to re-authenticate a user.
If so why cannot I use OAuth for authentication ?
Because Oauth knows nothing about who is preforming the task. It could be an application running in the background.
We are already using CAS for single sign on for several web applications that we are hosting. Now we are going to deploy several HTTP/REST services in our network and those need authentication and authorization.
Would it be a good idea to combine CAS with OAuth ?
Users would still use CAS for SSO, but additionally login procedure would issue OAuth ticket that would be used to access REST services.
REST services can be protected via CAS proxy authn. Additionally, they can be integrated with OAuth. CAS provides both OAuth and OIDC protocol functionality as well.
That's certainly valid. OAuth 2.0 doesn't specify/dictate how the user (Resource Owner) is authenticated and CAS/SSO is fine for that. Effectively you'd be leveraging a CASified Authorization Server so that the Resource Owner authenticates with CAS to the Authorization Server, which is "just" an application to the CAS SSO system. The Authorization Server would then issue an access token down to the Client so that the Client can use that access token to access the protected resources i.e. the REST services.
I am new to security domain, so don't know whether this question is valid to be asked here. I am currently using OpenAM for the security of my web application with J2ee agent, now I find that OpenAM can do authorization with OAUTH as well as on the basis policies defined, now both openam and oauth develops tokens for valid users, and do not share user credential with the application, so how different are the two? My second question is if my application does not support oauth like google and facebook what basic things I need to do to implement oauth into my application.
OpenAM supports OAuth based authorization if that is what your confusion is about. It also supports
1) OpenID Connect
2) SAML
Your application can use either of these to get authorization from OpenAM. Your application can also use the REST APIs for this purpose. The choice is yours.
As far as the tokens go, OAuth tokens are different from OpenAM Tokens. OAuth tokens include
1) refresh_token
2) access_token
The access_token is used for making oauth based calls. However, OpenAM tokens are basically what is there in the cookie or what you get via the REST API.
Regarding your second question, to support OAuth, you would need to use a oauth client library and enable oauth on the server side (in this case OpenAM). This client library would be dependent on the language you choose to write this application.