Tagged: , ,

This topic has 3 replies, 2 voices, and was last updated 6 years, 2 months ago by Guillaume Sauthier.

  • Author
    Posts
  • #10803
     conanmalone
    Participant

    Hi,

    Does anyone know if it’s possible to use OpenIG as an Oauth2.0 resource server and CAS as an authorization server? Quite new to both of the products and was hoping to get Oauth working as we are looking to implement SSO. We use RADIUS with our CAS server to allow us to use another authentication server that focuses on multi factor authentication (we use yubikeys and passwords) and store users in LDAP. So we were hoping that OpenIG would use CAS to do the authentication/authorization with our yubikeys and allow us access to a protected resource?

    Cheers

    #10807

    OpenIG can act as an OAuth 2.0 Resource Server if the AS provides a “token info” endpoint: it is used to verify the access token provided by the caller (authorization).

    I took a quick look at CAS, and they don’t mention such an endpoint: https://github.com/apereo/cas/blob/master/cas-server-documentation/installation/OAuth-OpenId-Authentication.md

    So unless I misread, or the info is somewhere else, I think that CAS cannot be used as an AS when IG plays the role of an RS.

    Now, if you want IG to be an OAuth 2.0 Client (or an OpenID Connect Relying Party), then, it seems that CAS can be used (this is the authentication part).

    #10809
     conanmalone
    Participant

    Ahhh apologies I misunderstood the difference between clients and resource server. I have set up OpenIG as a client on CAS and can go to my CAS server and generate a token for a user using OpenIG as the client ID. Would this mean I would need an additional server to act as a resource server? And do you know of any?

    How would I go about setting up OpenIG to try to gain access to a resource then use be redirected to CAS login page for authentication?

    #10810

    Ok, in that case, IG would protect of an application that needs to access resources protected by OAuth 2.0.
    That’s 2 completely separated concerns.

    Client will give you an access token that you can then use in the Authorization header when accessing a resources. The usage of that token is up to you: either you need to access a protected API directly, and in that case you must set up the header mentioned before, or this is the protected application that perform the call and need the token, in that case you should convey the token to the application (in a proprietary header), and then the protected app build the request to the API and use the provided token.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?