[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forgerock-openam
Subject:    [OpenAM] New to openAM and Single Sign-on.. HELP please
From:       johnpfc1 () gmail ! com (John pfc)
Date:       2010-11-26 10:48:18
Message-ID: AANLkTikYvfM8Pm10z+pmrhGkE7HUidCrLXoz_fVL5dME () mail ! gmail ! com
[Download RAW message or body]

Thank you S?bastien!


> I don't think so.  Usually, one single OpenAM instance per domain (circle
> of trust) is enough (excepted fro HA / load balancing - but this is another
> story)
>

When you say "usually only exists one single OpenAM instance per domain
(excepted fro HA / load balancing)" are you  saying that my main module and
the sub-modules should contact the IDP/OpenAM?

OpenAM has a session mechanism that works pretty much like an HttpSession :
> you can store any object in it and retrieve it as long as you are
> authenticated.
>

Can you send more information about the session mechanism? There is
documentation about it?

Best regards,

John

2010/11/26 S?bastien Stormacq <sebastien.stormacq at gmail.com>

> Hello,
>
>
> So, you think that isn't possible to use the policy agent for my Flex app?
> I can't use one policy agent within my application server and intercept the
> requests based on the gateway that was called? (ex: http://myapp/gateway )
> My concern with the Java API is related with the development needs to do the
> same that is available with one policy agent and the risks associated with
> this (Possible bugs).
>
>
> The OpenAM Policy Agents can perform authentication and authorization on a
> URL based policy.
> It can certainly handle authentication for your app (by enforcing
> authentication on your app URL) but it will not be suited for authorization
> as your application is likely to live entirely behind a single URL.  No
> granularity will be possible.  It will be an all GRANTED or REFUSED.
>
> Summary #1 : yes, you can use the policy agent for authentication
>
> Another problem that I can't figure out a solution is the authentication at
> the sub-modules of my application that are deployed in another JVM. How
> should I check if the token that is in the http request is valid? I need to
> contact my IDP?
>
>
> You can configure the agent to push some attribute to the application.  You
> should forward to your application the OpenAM Session ID.  Agents does
> receive it in a cookie and must forward it to your application.
>
> Your application must then be able to issue a call (Java API or web
> service) to OpenAM to validate that session (does it really exist ? is it
> expired ? ) and, optionally, to perform authorization.
>
>
>
> Currently, I have the following architecture:
>
> (1) 1 Tomcat instance with OpenSSO that is my IDP
> (2) 1 Tomcat instance with the main module, other modules of my application
> and one openSSO that contacts the first OpenSSO (using SDK) (1)
> (3) Others tomcat instances with some applications that contact the main
> module to check if the token that is in the http request is valid
>
> This scenario make sense? I really need to have 1 openSSO in the second
> tomcat?
>
>
> I don't think so.  Usually, one single OpenAM instance per domain (circle
> of trust) is enough (excepted fro HA / load balancing - but this is another
> story)
>
>
> How do you handle the need to share application context that is only
> available when I'm inside the main module (not at login time inside IDP)?
> The openAM provides a solution or I need to implement this feature using
> another thing?
>
>
> OpenAM has a session mechanism that works pretty much like an HttpSession :
> you can store any object in it and retrieve it as long as you are
> authenticated.
>
> Cheers
>
> Seb
>
>
> Thank you! _______________________________________________
>
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam
>
>
> --Seb
>
>
>
>
>
>
> _______________________________________________
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.forgerock.org/pipermail/openam/attachments/20101126/8f5a0c14/attachment.html 

[prev in list] [next in list] [prev in thread] [next in thread]