Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2013-11-23

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:46 jcwdev joined #openam
02:27 jcwdev joined #openam
02:36 jcwdev joined #openam
02:38 jcwdev Regarding the openig gateway: has anyone seen an implementation where is not designated as a full proxy for all traffic to flow through, but only directed towards in the absence of an application session for purposes of federated login negotiation?
02:41 jcwdev Perhaps this is not possible, just curious if anyone has seen it used that way.
02:48 * balo have never used openig
02:49 jcwdev :)
02:50 pdurbin jcwdev: like a Where Are You From service?
02:53 jcwdev Like... If my app does not have an active session, forward the user to openig for saml2 negotiation with the remote IdP, after negotiation parse assertions and redirect user back to application with a signed hash of assertions in the header (with private key held by openig) which my app trusts and so trusts the assertions, therefore issues a session.
02:55 jcwdev My problem is that my architecture prevents me from layering openig in the middle of every request, so I want it to handle a request for SP initiated federated login in the absence of sessions, but not sit in front of every request.
02:55 pdurbin jcwdev: sounds fine but wouldn't you have already set up a trust between your SP and the IdP? That's not enough?
02:57 jcwdev Imagine openig and my application living at two different domain names. The app directing the user to openig just for federated SAML processing. The fact that they live in separate systems and openig is no longer an absolute proxy means I have to establish trust between my app and openig
02:58 jcwdev At least in my head it does. :)
02:58 jcwdev I'm halfway waiting for someone to tell me that I'm a moron and to please be quiet ;)
03:00 pdurbin_m joined #openam
03:01 pdurbin_m jcwdev: dropped connection. keep talking and I'll read the IRC logs
03:13 jcwdev Ok. So... What I'm looking for is an authentication gateway which only ever sees traffic looking to login to a federated system via saml2. Such that my applications can redirect unauthenticated (sessionless) requests to the gateway (which lives on a separate host) and the gateway will (by the target URL) know which IdP to initiate a SP initiated SAML handshake with. When the IdP returns the user to the gateway with a SAML token the gat
03:13 jcwdev can validate the signature and extract the assertions. Once extracted, it should construct a hash of the assertion data and sign that hash, posting the hash, signature, and assertion components to a special application handler which trusts the assertions by virtue of the gateways signature on the hash.
03:14 jcwdev This way my applications could all know how to exchange information with and trust a single gateway implementation, but be oblivious to everything else about the login process.
03:16 jcwdev I could then drop in IdPs to handle any specific integration in any environment without requiring my application to have any knowledge of how that is implemented, aside from the fact that sometimes users are redirected from the gateway with some assertions and a signature that it respects.
03:17 jcwdev The entire point is to get the effect of openig without having to route ALL application traffic through the gateway.
03:18 jcwdev I run in EC2 and my use of elastic load balances and other facilities prevents me from laying openIG in the middle of every request without introducing some single points of failure that I am trying to defend against.
03:20 jcwdev And maybe some latency too?
03:20 jcwdev I have been reading about the openIG process and it's fits exactly what I need... Almost :)
03:30 jcwdev joined #openam
03:39 jcwdev Seems like it should be programmable enough to do this... I just don't know if I can make it redirect the user instead of passing the assertions directly to an upstream server.
03:39 jcwdev Anyhow, thanks for listening to my ramble :)
03:59 jcwdev joined #openam
04:01 jcwdev_ joined #openam
06:29 jcwdev joined #openam
07:46 ludovicp joined #openam
08:34 jcwdev joined #openam
08:37 jcwdev Building OpenIG today...
08:37 jcwdev Building OpenIG Federation web application 2.1.0
08:37 jcwdev I cannot reach a repository listed in pom.xml
08:37 jcwdev Could not transfer artifact com.forgerock.openam:sharedlib:pom:10.0.0 from/to forgerock (http://repo.forgerock.org): repo.forgerock.org: Unknown host repo.forgerock.org
08:44 jcwdev Downloading: http://repo.forgerock.org/com/forgerock/openam/sharedlib/10.0.0/sharedlib-10.0.0.pom
08:44 jcwdev Looks like the repository host mentioned does not exist. is there a URL  to replace this with?
08:55 aldaris joined #openam
10:08 balo >http://maven.forgerock.org/repo
11:04 aldaris joined #openam
11:14 aldaris yepp, but the artifact names have changed too
11:14 aldaris looks like someone should update openig poms..
11:15 aldaris jcwdev I'm not sure about the SPOF part of your comments
11:15 aldaris if you have an application somewhere then surely you should be able to deploy openig on that same container into the / contextroot
11:15 aldaris I think that should work
11:17 aldaris jcwdev, while your thoughts looks okay they require custom code just as much… I mean then you have to send requests to this gateway only if the session is invalid (how do you know if the session gets invalidated???)
14:14 Hunger- joined #openam
18:33 MegaMatt joined #openam
19:31 jcwdev joined #openam
19:55 jcwdev joined #openam
19:56 jcwdev balo: thank you!
19:57 jcwdev oh, artifact names. i see.
20:00 jcwdev @aldaris i would know that application session is invalidated/expired, but not that the federated login was expired or invalidated.
20:01 aldaris yeah, that isn't really helpful imo
20:01 jcwdev So you are suggesting that if I have an application on three servers behind a load balancer, that I could install openIG on each application instance.
20:02 jcwdev (each server)
20:02 aldaris I'm not like 100% sure
20:02 jcwdev :)
20:02 aldaris but I think so
20:02 jcwdev gotcha
20:04 jcwdev i wonder, how does openIG know that the federated login has expired. it would be in the same situation unless that's part of the saml handshake, that this token is good until X time
20:04 aldaris I don't know how openig really implements saml
20:05 aldaris but normally you could set up slo and then openig receives the logout request from openam
20:05 jcwdev i see.
20:05 aldaris you could even enable session synchronization in openam and then AM would fire off a SOAP SLO request upon session timeout
20:06 jcwdev that SOAP SLO call is directed at the gateway?
20:06 jcwdev or the IdP
20:06 aldaris well the IdP would send the SOAP SLO call to the gateway
20:07 jcwdev i see.
20:07 aldaris if IG actually exposes an SLO endpoint
20:07 aldaris I really haven't used IG yet
20:07 jcwdev it certainly seems interesting
20:07 jcwdev in my case, I have partners that want to federate these identities, so I'm not in control of the IdP
20:08 jcwdev except in test environments.
20:08 jcwdev not really a SAML guru here - so I'm trying to learn how all of this works.
20:16 jcwdev so, taking a step back from openIG. if i were to deploy openAM + policy agents on my tomcat containers. the policy agents would have to know about the openAM server in order to pull their policy configurations of course. but they would not have to know about each other at all. does that sound like a correct statement?
20:19 jcwdev from the docs i have read it seems to be the case.
20:19 aldaris the agents don't need to know about other agents
20:19 aldaris they only access AM
20:20 jcwdev cool, i figured, but i had someone challenge me on the scenario of SP initiated login to a federating IdP
20:20 jcwdev where one agent initiates, the IdP logs the min and redirects, and another agent receives.
20:23 aldaris you mean you have a single clustered application with agents for each cluster member?
20:25 jcwdev yes
20:25 aldaris and is that a java ee agent or a web agent?
20:27 jcwdev java ee - however, we don't use the clustering functionality in Tomcat. Our user sessions are centralized in memcache+dynamodb solution, so servers don't share session state, they read it from a central repo.
20:27 aldaris alrighty
20:28 aldaris as long as the jee agents are using the same am.encryption.pwd setting (see bootstrap properties), everything should be fine
20:28 jcwdev right… because they ail pall initiate the handshake the same way?
20:28 jcwdev all will*
20:28 jcwdev makes sense
20:28 aldaris not sure what you mean by handshake
20:29 aldaris but basically they all work the same way obviously
20:29 aldaris in case of cdsso they create an encrypted cookie
20:29 aldaris so the encryption.pwd needs to be the same so the agent can decrypt it when you get back from auth
20:29 jcwdev sorry poor term, i mean they will all perform the SP initiated login request the same way
20:30 aldaris see OPENAM-28 to deal with SAML login :)
20:30 jcwdev ok :)
20:35 jcwdev thanks for the feedback aldaris :)
20:35 jcwdev it has been very helpful
20:42 aldaris joined #openam
21:16 aldaris joined #openam
21:16 jcwdev joined #openam
21:30 ludovicp joined #openam
22:04 aldaris joined #openam
22:48 aldaris joined #openam
23:40 aldaris joined #openam

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary