Re: [cas-user] SimpleHttpClient.java Security Review positive to DOS
>
> boolean readInput = true;
> while (readInput) {
> readInput =StringUtils.isNotBlank(in.readLine());
> }
>
There's absolutely nothing wrong with that line in the overall design of
the reader. The whole purpose of the component is to buffer the entire
stream contents in memory, regardless of whether it's done line-by-line or
all-in-one. The end result is the same.
While there may be some merit to the criticism that buffering the entire
response creates a DOS vector, it's hardly uncommon and is the only way to
parse XML via DOM.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS MFA, session, and TGT cookie
> > I'd like to know if a user is 'authorized' to login to a service once they > have a session (JSessionID), or are they only authorized after the TGT > cookie has been set? > We modified the login flow a while back to check the service against the ServiceRegistry in the first few steps of the flow, long before authentication and/or ST creation. It's pretty much first thing nowadays. You can dig through the CAS Jira for the issue to see if your version includes the fix. (Pretty sure it was fixed when we were still on Jira.) M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Apps running amok with service ticket validation requests
We have seen these on the order of ~1500/minute for anywhere from a few minutes to a few hours in duration. In my experience ticket floods are always caused by misconfigured applications. In one extreme case we got ~42K in a ~60s period. We never zeroed in on the exact cause, but we do see lots of clients misbehaving from time to time. I would be concerned about a regular occurrence at the rate you mentioned. When this occurs, it's for a seemingly arbitrary user of the app. We've only seen this with three of our several hundred registered applications/service URLs. I would recommend contacting the administrators of those services and start troubleshooting. It's almost certainly some kind of application design or configuration problem. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Service Ticket Timeout Policy
Lately we have been seeing ST Validations failing because the ticket is expired. We are thinking of changing the timeout to either 15 or 20 seconds. The first thing that occurs to me is latency in ticket replication among all the peers in your cluster. That's sort of orthogonal to your question, but the root cause is interesting. And it's just a thought, could be any number of things. In any case I'd be interested to know the root cause if you drill into it and figure out, particularly if it turns out to be repl latency. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Querying CAS audit data with Splunk
Yes, I have some nice splunk dashboards for CAS I can share if there is interest. If you have a dashboard/query that can follow all service accesses in a single SSO session, then I would be very interested. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Querying CAS audit data with Splunk
FWIW, the underlying Inspektr's component that CAS uses for its slf4j audit events destination is extensible, and one could always plugin their own output formatting implementation to suit their needs: Sure, and we have extended it locally for our deployment. I think it's fair to consider, however, whether the defaults are convenient for common query cases. For anyone ingesting logs into Splunk, the layout is indeed quite inconvenient. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Querying CAS audit data with Splunk
Nothing that follows every service access-- I think that will require some unusual joins. I got a working query that wasn't too bad: index=mwcas sourcetype=mwcas-audit | rex (?tgtTGT-[A-Za-z0-9_-]+) | rex (?servicehttps://[A-Za-z0-9._/-]+) | transaction tgt maxspan=10h keepevicted=true | regex principal=[A-Za-z0-9_.-]+@.* | chart count by service The key was to create on-demand field extractions using rex to look anywhere in the audit entry for the correlating TGT. FWIW, the purpose of the query is to identify what services our guest users (identified by email addresses) are accessing. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] phpCAS Error
The root problem:
44B4 .||||= CAS_Client::_readURL('
https://10.0.12.81:8443/serviceValidate?service=http%3A%2F%2Flocalhost%2Fdemo%2Fta%2Fcas5%2Fticket=ST-13-W3OmeHczcuhJOGeiwaeO-cas.poliupg.ac.id',
NULL, NULL, NULL) [Client.php:3118]
44B4 .|||||= CAS_Request_CurlRequest::sendRequest()
[AbstractRequest.php:242]
44B4 .||||||curl_exec() failed [CurlRequest.php:77]
Common causes are networking issues (i.e. firewall) and SSL certificate
trust problems. The fact that you're trying to reach a private address (
10.0.0.0/8) looks suspicious.
phpCAS::setNoCasServerValidation();
Since you have this set, it's not an SSL trust problem, but I would
encourage configuring SSL trust before you put this into production. I see
you're attempting to reach a host by IP address, which causes headaches
when doing SSL trust evaluation. I suggest you use a hostname if possible
when you get around to enabling SSL trust validation.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] shib idp 3 CAS support
The primary reason I did not like the memcached implementation was that it is not truly fault-tolerant. As I understand it, any given key is hashed and stored on one of the available memcached nodes. A client that needs it performs the same hash, and tries to retrieve it from the same node. I have a three node CAS cluster. With the memcached ticket registry, if one of the nodes were to crash, I would simply lose a third of my state. Correct. What makes this acceptable in many if not most cases is that the lost state is SSO state where the effect on the user is to log in again. As failure modes go, that's graceful behavior. On the other hand, with the hazelcast ticket registry backend, a backup copy of the state on any given node is available on another node, and if you lose only a single node, you lose no state. Peer-to-peer replication incurs a cost and in my experience the failure modes of replication are orders of magnitude worse than anything I've seen with memcached. Perhaps over time Hazelcast will prove itself both reliable and fault tolerant, but it's patently new technology at this point and needs some road time to convince me. Best, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] shib idp 3 CAS support
Would the idp multifactor mechanisms be usable for CAS clients? Yes, though it may be better to discuss further on the related shib-users thread. I don't particularly like the memcached backend, which looks like the only current option (other than a database) to cluster idp 3. I'd be curious to know why you don't like it. I encourage you to discuss further on shib-users. Yes, from what I've seen the attribute filter basically functions as the service registry for CAS clients, but gives you the idp feature of only allowing certain values of some attributes rather than all. The ability to mutate attributes is a notable capability of the IdP attribute engine. I need to decide whether to keep a separate CAS deployment ... or migrate CAS clients to the idp CAS support. I was in the same situation, so I'll share my decision FWIW. I'm a single FTE running two production systems, Shib IdP and Jasig CAS server, that have the same purpose but with complementary capabilities. It made all the sense in the world to consolidate onto a single platform that could provide everything we needed. Fortunately I had the benefit of developing the CAS protocol support in the IdP expressly to meet our requirements. Thus we had assurance our needs would be met by a single platform and it became a straightforward economic decision: consolidate and save. Of course our needs and yours are likely different; you'll have to evaluate for yourself whether a single platform meets your requirements. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] shib idp 3 CAS support
I was just wondering if anybody here is familiar with both and might be able to provide some pros/cons of consolidating CAS into the idp vs continuing to maintain a separate CAS deployment? I'm very familiar with both from a development and deployment perspective. Much of the growth of Jasig CAS over the past several years has been in the area of multi-protocol support, so you'll lose anything that's not CAS or SAML; OAuth protocol support comes to mind. That's probably the biggest functional area of distinction. I would say Jasig CAS has more mature management capabilities; the service manager UI comes to mind immediately. That said, it's only a matter of time and effort before the IdP catches up in that area. There are also a lot more integration options for Jasig CAS, mostly in the area of storage backends like Ehcache and Hazelcast. Again, it's easy to develop these things for the IdP and they will probably emerge in the near future if folks need or want them. On balance, the attribute engine of the IdP is a powerful capability that has no analogue in Jasig CAS. I could probably come up with some more pros and cons to discuss, but the ones I've listed seem most notable to me as a deployer. If there are any features of interest to you in particular, please mention them and we can discuss further. Best, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
We've been running a load-balanced CAS cluster of two nodes for a number of years now. Clustering is supported provided you have session affinity during the login process. If anyone has achieved truly stateless clustering, it would include session replication among cluster nodes (among other things), with resulting dramatic increase in complexity. Is there any reason you can't configure your cluster for session affinity? Session affinity is standard practice in the HA deployments I'm aware of. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
Personally, we just set up our three-node CAS4 instance with Hazelcast and front-ended it with our Barracuda (no special config required.) I'm fairly certain the back end ticket store is irrelevant here. The poster appears to be discussing fully stateless clustering, which involves special (and difficult) distribution of servlet session data between all nodes. Most HA deployments don't care about node loss during the relatively short-lived login process. To the user it would just appear as a glitch when the LB/app router/whatever routes to a new node that doesn't know what session is described by the posted JSESSIONID cookie. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Problem with CAS Clustering and LT parameter
I'm only considering shared sessions because that seems to be what's recommended in the CAS wiki. I don't feel like the CAS wiki ever had any good high-level discussion of HA. In any case the new-ish CAS4 documentation has a HA page that spells out session affinity as a requirement for active/active deployments: http://jasig.github.io/cas/4.0.x/planning/High-Availability-Guide.html Our networking team was unsure how sticky sessions at the load balancer would affect things (like applications validating STs, etc). It tends to create hot spots on one node for a particular service, thus if you have a single that produces the heaviest load on CAS, it till tend to get pegged to a single node instead of distributing load throughout all peers in the pool. Failover characteristics are exactly the same as without session affinity. We've found that hot spots can cause trouble in fairly extreme circumstances [1], but in most cases it's a non-issue. M [1] Once a CAS-enabled timeclock application got in a redirect loop that generated millions of service tickets in a ~120m period. Our service, remarkably, held up due to a cache-backed ticket registry that simply purged old entries to hold the flood of tickets. The CPU on the node handling all that traffic went red and sent off alarms, but held up admirably. -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Embedding username info in Service ticket
I do have a secure mechanism to encrypt my service ticket with the public key and then decrypt it later using the private-key. At that point you've created your own SSO protocol and you're more or less on your own as to the security outcomes. If you need security assertions that are valid without a centralized authority, SAML comes to mind as a protocol that has that characteristic. In any case I strongly recommend you stick with proven standards. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS status - Free memory threshold Warning 10% - HTTP 400 error code
At times we get we get WARN notifications with HTTP 400 status code... That's by design and intended to be simply a warning; you can respond in whatever fashion you think prudent or necessary. I would imagine that if it starts to happen regularly, you would take that as a sign to increase your heap via the -Xmx JVM flag. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Understanding CAS and SAML
https://wiki.jasig.org/display/CAS/Shawn+CAS+and+SAML First, that document is very old. May still be relevant, but just as likely not. I was under the impression that when using SAML you initiate a SSO with a so called authnRequest. https://wiki.jasig.org/display/CASUM/SAML+1.1 provides actual messages captured from log output of an old but not ancient client and server conversation. That's a better reference for understanding message exchange. In SAML parlance, this is an SSO browser/artifact profile request over SOAP binding. Note that neither the request nor the response are signed, which is uncommon in the SAML world. The JASIG CAS server implementation of SAML 1.1 derives security from the bearer token model used in the CAS protocol. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Which version sould I upgrate to 3.5.3 or 4.01
Same as object I'm coming from 3.4.3 and looking for and advice if is better to go straight to 4.0.1 or maybe stop at 3.5.3 There will be more configuration work to upgrade from 3.x to 4.x, but it's work you'll have to do eventually since the 3.5.x branch is in maintenance-only mode. My recommendation is try to upgrade to 4.x as soon as possible. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Certificates and Active Directory
This seems to be a new requirement for cas server 4.0. I suppose it could be the new version of java (1.7) causing the requirement. Not Java per se but the LDAP integration library. CAS 4.0 uses the ldaptive library for LDAP integration, and it has strict hostname verification enabled by default, which is the most secure option. You can read more about the behavior here: http://www.ldaptive.org/docs/guide/connections#TOC-Hostname-Validation You could customize the behavior by implementing one of these: http://vt-middleware.googlecode.com/svn/ldaptive/javadoc/bundle-1.0.5/org/ldaptive/ssl/CertificateHostnameVerifier.html It's a very simple interface, so it should be straightforward to develop a custom strategy. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Can we use sAMAAcountName for single-step authentication without needing to know DN
I would like to use Method 1 (Active Directory authentication using sAMAAccountName) if possible without using two-step authentication using a service account to obtain the user DN. Yes. Is this possible without having all users in the same LDAP tree? It should be possible. Can you please try and report back with your results? Thanks, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] I am lost... And in desperate need of help
With Prod 3.4.12 and MFA, don’t get the successful login page. I get “page not found” in the browser. Turn the org.jasig.casup to DEBUG and post (sanitized) logs corresponding to the 404 error you mentioned. The error goes away if I take one of the 2 CAS servers offline. Did you ever solve your ticket registry replication problems? I wouldn't think that a ticket not found error would cause authentication problems, but this sure sounds like some kind of HA config problem. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] cas 4 lppe configuration for password
Is it me or does this log say that the PASSWORD_MUST_CHANGE error is not getting processed with the authenticationExceptionHandler.handle(currentEvent.attributes.error, messageContext) properly. Not sure. Did you get any output from the TRACE logger I recommended enabling? M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] cas 4 lppe configuration for password
2015-02-24 14:20:57,866 DEBUG [org.jasig.cas.authentication.support.DefaultAccountStateHandler] - Handling PASSWORD_MUST_CHANGE An AccountPasswordMustChangeException was thrown here. Something in the view layer is supposed to catch that and route the user appropriately. org.jasig.cas.web.flow.AuthenticationExceptionHandler is the key component to bridge authentication errors with view dispatching. There's a TRACE-level logger on that component that's worth enabling and trying again. It emits a message if no mapping is found. You should scan your login-webflow.xml and make sure it contains a reference to AuthenticationExceptionHandler, which is defined in cas-servlet.xml. All this is configured by default in 4.0.1, so unless you changed it, you should be good. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Logout view not following server url redirects
My 3.5.2 CAS server is not following redirects on logout. Do you have some evidence to share? Not much changed on HttpClient between 3.4.12 and 3.5.2 [1], other than adding the followServiceRedirects flag which previously defaulted to true. Turn up org.jasig.cas.util to DEBUG and see if you get any hints. M [1] https://github.com/Jasig/cas/commit/01c3e87fe2697a06c3efc94d606e1311633bb396 -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Client: SilkRoad Life Suite
Re: SilkRoad Life Suite In light of current events around the _other_ Silk Road, that seems like a very unfortunate product name. I hadn't even heard of it, much less have any experience. Maybe someone else does. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] org.jasig.cas.client.validation.TicketValidationException
They have noticed that their log files are filled with the above exception and have asked me to help them resolve this. Are they using the SAML 1.1 protocol perchance, say to get attributes? The CAS client enforces the SAML assertion validity window, which is a unique feature of SAML. Clock drift can be an insidious cause of ticket validation failures with that protocol. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS server release v3.5.3
You know what you don't do for a minor weakness? Publish a CVE with a title including allows remote attackers to bypass LDAP authentication via crafted wildcards. Paul, I get your frustration and I can sympathize. The CVE appeared to come at us from outside the project, and its eminent publishing prompted the release and arguably poorly crafted security advisory from us. You can chalk that up to haste on our part. On balance, we felt it best to have a patched version available for download _prior_ to the CVE getting published. As for the CVE text itself, I have no idea where it came from. I don't believe it came from the core dev team. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0 w/ OpenLDAP won't return memberOf attribute
It seems like it would be more efficient if I could just have CAS return
the attributes that it is able to retrieve using the
LdapAuthenticationHandler.
That is indeed desirable and entirely possible using
LdapAuthenticationHandler and a static person directory attribute resolver.
The key is _not_ configuring a principal resolver for the
LdapAuthenticationHandler bean in the PolicyBasedAuthenticationManager
constructor:
bean id=authenticationManager
class=org.jasig.cas.authentication.PolicyBasedAuthenticationManager
constructor-arg
map
entry key-ref=proxyAuthenticationHandler
value-ref=proxyPrincipalResolver /
entry key-ref=primaryAuthenticationHandler
value=#{null} /
/map
/constructor-arg
If no resolver is defined for a handler, that signals the authentication
manager to use the principal resolved from the authentication handler.
Hope that helps,
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0 w/ OpenLDAP won't return memberOf attribute
It is definitely not specifying the return attributes.
That jibes with the CAS logs. The following is the log entry for the search
operation for return attributes following user bind:
2015-01-14 10:03:31,357 DEBUG [org.ldaptive.SearchOperation] - execute
response=[org.ldaptive.Response@1642731964::result=[[[dn=cn=roger.rabbit,ou=casusers,dc=xyz,dc=net[],
responseControls=null, messageId=-1]]], resultCode=SUCCESS, message=null,
matchedDn=null, responseControls=null, referralURLs=null, messageId=-1] for
request=[org.ldaptive.SearchRequest@-349299973::baseDn=ou=casusers,dc=xyz,dc=net,
searchFilter=[org.ldaptive.SearchFilter@2101991669::filter=uid={user},
parameters={user=roger.rabbit}], returnAttributes=[1.1],
searchScope=ONELEVEL, timeLimit=0, sizeLimit=0, derefAliases=null,
typesOnly=false, binaryAttributes=null, sortBehavior=UNORDERED,
searchEntryHandlers=null, searchReferenceHandlers=null, controls=null,
followReferrals=false, intermediateResponseHandlers=null]
Note returnAttributes=[1.1]. I believe that's logged to indicate default
behavior, which is no attributes. My hunch is that initialize is not being
called on your LdapAuthenticationHandler bean, which prepares the list of
return attributes from property values. Try adding the init-method
attribute to your bean definition as follows:
bean id=ldapAuthenticationHandler
class=org.jasig.cas.authentication.LdapAuthenticationHandler
p:principalIdAttribute=uid
c:authenticator-ref=authenticator
init-method=initialize
...
/bean
You should see returnAttributes in the cas.log file with the attributes
you've configured. It's not working correctly until you see that.
Best,
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0 w/ OpenLDAP won't return memberOf attribute
If I use the manager account that is used to search the directory or the credentials of the use who is logging in with ldapsearch, as long as I explicitly request the memberOf attribute it gets returned. Ok, then my hypothesis is apparently wrong. Requesting the additional attributes at authentication time is still preferable for efficiency, so I suggest you continue with that approach. Are you saying that I should put all my attributes that I want returned here: bean id=ldapAuthenticationHandler class=org.jasig.cas.authentication.LdapAuthenticationHandler Correct. When I did this I end up getting back just the values I specify in the stub, not the values of LDAP. Can you please put the org.jasig.cas.authentication and org.ldaptive packages in debug and post the logs? M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
Yes, after every chage I do: mvn clean package ./bin/shutdown.sh rm -r webapps/cas/ work/ logs/* cp target/cas.war ./bin/startup.sh That should work, but you might also try clearing out the unpacked war files under (IIRC) $CATALINA_HOME/temp. I have a habit of clearing out those files as part of the redeploy process since I had some evidence of changes not taking in the past. Can't hurt in any case. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] working example? cas 4.0.0 LDAP deployerConfigContext
Here is the link to the xml: http://pastebin.com/N20RzJgG The file looks ok on visual inspection and passes XML validation using tools. That makes me think that the whitespace issue that Curtis mentioned is perhaps the cause. It's possible the whitespace got fixed between pastebin and the editor I used to view the file, which would explain why it's broken for you and seemingly ok to me. I suggest you ensure you have consistent LF (Unix) or CRLF (windows) line endings. Here's a Unix one-liner to convert to exclusively LF line endings: tr -d '\r' deployerConfigContext.xml deployerConfigContext-new.xml M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] working example? cas 4.0.0 LDAP deployerConfigContext
INFO: Deploying web application directory /var/lib/tomcat7/webapps/ROOT 2015-01-07 11:04:42,372 ERROR [org.springframework.web.context.ContextLoader] - Context initialization failed org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 72 in XML document from ServletContext resource [/WEB-INF/deployerConfigContext.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 72; columnNumber: 9; cvc-complex-type.2.3: Element 'beans' cannot have character [children], because the type's content type is element-only. This error indicates you have non-whitespace character content under the beans element somewhere. I can't see it in your post, but the XML is hard to read so it's not surprising. Can you post your file on pastebin or similar so I can read it clearly? Thanks, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Inclusion of auditTrailManager.xml
Good Afternoon from the cold, dark north as we near winter solstice. Yikes! It's hard to imagine only a few hours of light per day. How much overhead does adding the audit trail logging add? It logs to a file on a background worker thread, so hardly any. You can choose other backends, but file is simplest and arguably fastest. Where is this documented so I can control how much it spews? https://wiki.jasig.org/display/CASUM/Auditing+and+Statistics+Via+Inspektr Not sure it provides much guidance on controlling verbosity, though it's certainly possible to tweak. I'd recommend using the default and tweaking as needed after you collect some data. I'm optimistic what we provide out of box will be suitable. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Rapid Memory Consumption and Interpreting Heap Dump
it should not be able to fill the heap memory of the SSO server which would argue that there is some bug in the CAS SAML code that is being excercised by the repeated logins. You attached a profiler screenshot near the beginning of the thread that showed a large number of GoogleAccountsService objects holding onto memory. I should note that GAS holds references to the keypair used to sign/verify SAML assertions. Assuming you're using at least a 2048-bit RSA key for that, that's at least 512 bytes (2048/8*2) per instance. Your profiler screenshot is showing ~1.7M instances of that class consuming 76MB memory, which doesn't add up AFAICT. In any case I could see why excessive numbers of that class would cause trouble, but I don't have an explanation for why there are so many allocated. Perhaps we do have a resource leak here. I suggest you create an issue an attach all data you have, especially profiler data, and we can investigate further. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Rapid Memory Consumption and Interpreting Heap Dump
Second, the massive number of STs are being created on only one server (we can tell by the host name in the logged ST) but the OTHER SERVER is where the memory is growing out of bounds. I'm still working through this thread, but I wanted to point out that the other is hurting likely because of load balancer session affinity. Recall that ticket validation is a back-channel call, and the network source differs from that of the user's browser. In our environment, services typically get stuck on one node causing hot spots. This is because the service is validating tickets frequently enough that the session affinity timeout never kicks in. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Multiple environments with different bean properties values
we have some custom bean properties, but depending on the environment have different values, e.g. !-- Test environment -- property name=baseUrl value=https://test.wyona.com// !-- Production environment -- property name=baseUrl value=https://www.wyona.com// The Spring profile machinery is intended to address this problem: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-definition-profiles Really, the core decision is whether to do runtime or build-time configuration (e.g Maven profiles). Over time I have moved from build-time configuration to runtime, which in part has happened because the Spring facilities have improved so much. In the end it's largely a matter of preference. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] BcryptPassword Encoder
bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder p:characterEncoding=UTF-8 c:encodingAlgorithm=BCryptPasswordEncoder/ BCryptPassword is not a valid JCE digest algorithm name. You must use one of the values described in the following document: https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0 Production Issue: Heap Memory Issue
For the the second time both of our SSO servers running under Tomcat ran out of heap memory last night. Did CAS emit any errors to the application log file, cas.log, prior to OOM? Please post anything you have. You can configure the JVM to perform a heap dump prior to exiting, which you should set up immediately so you have some additional information if/when it happens next time. The follow system properties should do the trick: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/jvm-dump.hprof You might also consider taking periodic heap dumps using the jmap tool and analyzing offline using some analysis tool. We use the YourKit Java profile for this kind of thing, fwiw. Hope that helps, M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0 Production Issue: Heap Memory Issue
Do those setting go in CATALINA_OPTS or JAVA_OPTS in the setenv.sh file? The Tomcat documentation recommends CATALINA_OPTS, which is what I do. M http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] HA system map for CAS
We are looking to deploy an HA architecture for CAS. We will have a load balancer with a server on two different campuses. I believe the following documentation will be helpful: http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html The Recommended Architecture diagram is effectively the architecture of Virginia Tech's HA deployment. We use memcached for ticket storage for what it's worth, but many folks use Ehcache and increasingly Hazelcast. Your ticket storage backend is arguably the most important system component, so choose wisely. Best, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0 Production Error - java.lang.OutOfMemoryError: Java heap space
We've looked at https://server/cas/status but can't tell if the memory usage there includes an ehcache ticket registry or if that is excluded. The MemoryMonitor simply looks at overall JVM memory usage. While ehcache may, depending on configuration, use off-heap memory allocations that are invisible to this monitor, the condition you reported should have been detectable with MemoryMonitor enabled. That said, there may be better monitoring and reporting tools to help avoid this situation in the future. I know I've asked this question before and never gotten an answer (maybe no one knows), but is there any way we can monitor the number of tickets (TGTs, LTs, STs) in an ehcache? If you use separate cache instances for each ticket type, you can get total object counts _or_ byte counts with EhCacheMonitor; if you use a single cache instance (common) for all tickets, you get only a single total for all tickets. Reviewing the following code may help: https://github.com/Jasig/cas/blob/f149144d7258dd592c38bc4325b0aa9d7159860d/cas-server-integration-ehcache/src/main/java/org/jasig/cas/monitor/EhCacheStatistics.java Finally, are there any best practices surrounding regular restarts of the servers (any known memory leaks, etc) and what would the timing of those restarts need to be? Scheduled restarts simply are not a best practice. I would try to solve the root problem, and punt to scheduled restarts as an option of last resort if you can't fix the cause. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 3.5.2 - SQL Deadlocks - Not cleanup related
Can anybody shed some light on this, please? Any thoughts on where to look? It's a known issue and there's little remedy. Searching the list archives you'll find that deadlocks are most commonplace on MSSQL. We've tried several fixes to reduce the likelihood of deadlocks, but nothing short of an API change will solve the problem in a truly satisfactory manner. I would recommend a cache-based ticket registry like memcached, Ehcache, or Hazelcast. I will say that many folks have achieved performance with acceptably low deadlock rates with JpaTicketRegistry on other database platforms. I have personal experience with PostgreSQL and Oracle, and both performed acceptably well. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 3.5.2 - SQL Deadlocks - Not cleanup related
I saw the JIRA from a couple years ago that got marked as resolved after you merged a patch. Can you cite the Jira issue? There have been a couple IIRC. Is there anything I can provide that would make it worthwhile to reopen it? Possibly. There's a deadlock generator script that I used to reproduce the issue while working on the original patch. I'm open to additional patches, but any candidate fix that does not improve behavior against that script is a no-go. I believe the script is attached to a Jira issue, but I can make available if needed. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 3.5.2 and CVE-2014-3566, POODLE
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:341) org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:305) Please perform an SSL trace and post the log. If it's not happening immediately, you'll need to trim the log to correspond with the failure point. The trace will provide more information on why the handshake is failing. M [1] https://wiki.jasig.org/display/CASUM/SSL+Troubleshooting+and+Reference+Guide, When All Else Fails section -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Has anybody done this?
I believe this additional step is for anti-phishing. It is for the site to verify its authenticity to the user, not for the user to verify their authenticity to the site. FWIW, that is my understanding as well. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Can Central Authentication Service (CAS) do authorization and use LDAP ? (Example ?)
I'm a little confused about the authorization, which I read CAS isn't supposed to do. CAS doesn't provide any support for centralized authorization policy, but it can provide data to applications that support application-specific authorization policy. We use the term attribute release in the documentation for this feature. Yet, I see something like groups, but don't know what they are. Where do you see this? It's common for CAS to load group membership data for a user on authentication and give it back to services when the service is authenticated to CAS. Anyway, my scenario is pretty common, and is as follows: We need to restrict access to each of our apps that are going to support SSO. Within each of our apps, there are roles in LDAP tree. These roles are used to prevent certain users from accessing various parts of the site. CAS could release the role data to the application and it would then have to enforce the policy restrictions based on that data. Also, an admin of one system may not be an admin of another system. Is it possible to satisfy all of these scenarios with CAS? It sounds to me more like a requirement of the group/role data in your system of record for user data. CAS can release whatever data for a user you tell it to. Note, however, that it must be modeled as user data. There's no way to ask CAS what is the data for this user at this particular this service. You load up all user data at authentication time and return some or all of it to an authenticating application when it talks to CAS. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Can Central Authentication Service (CAS) do authorization and use LDAP ? (Example ?)
I don't understand your answer The answer is nuanced, sorry. Can Central Authentication Service (CAS) do authorization and use LDAP ? CAS cannot do centralized authorization. It can support authorization at each service by providing data from a system of record (e.g. LDAP). CAS has a number of components to support both authentication and authorization using LDAP. I would like an example Best we got: http://jasig.github.io/cas/4.0.0/installation/LDAP-Authentication.html Search the list archives and the CASUM wiki for more. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Can Central Authentication Service (CAS) do authorization and use LDAP ? (Example ?)
I would like authorization with LDAP by CAS Server of applications web (services) Please read the following section of the CAS 4 user manual: http://jasig.github.io/cas/4.0.0/integration/Attribute-Release.html That provides a high-level overview of how CAS participates and facilitates authorization through attribute release. Note there is an LDAP component, LdapPersonAttributeDao. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] MFA Duo support for 4.x
What are members of this community currently using, looking into, or developing for MFA via Duo? We quickly prototyped two MFA solutions on top of 3.5.2, one for Google Authenticator and another for YubiKey. Almost all the customization was at the WebFlow layer. Assuming you approach a solution similarly, I would expect any code for 3.5.x to port to 4.x with minor changes. I would also argue that the enrollment and backup processes (no token/device) are so specific to each institution that it's hard to develop a general framework. That's to say I would think rolling your own is necessary, and our experiments show it's fairly easy for a development team familiar with Java/Spring. Best, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Preferred HA clustering support
For a high-availability cluster, just follow the instructions here: http://www.howtoforge.com/how-to-install-repcached-memcached-replication-for-high-availability-over-2-nodes-on-ubuntu-11.04 I attempted to provide a thoughtful explanation in the CAS 4 documentation why memcached replication is unnecessary for many deployments: http://jasig.github.io/cas/4.0.0/installation/Memcached-Ticket-Registry.html#high-availability-considerations I'll leave it to you to determine whether you need replication. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] client side password encryption
SSL/TLS is mandate. Along with that I need to client-side password encryption also. I encourage you to reconsider. I realize that may be difficult if the requirements are dictated by a third party, but it's worth repeating that this is most likely a bad idea. In particular the key management issue is much harder than the cryptographic algorithm implementation: Successful key management is critical to the security of a cryptosystem. In practice it is arguably the most difficult aspect of cryptography because it involves system policy, user training, organizational and departmental interactions, and coordination between all of these elements. [1] If you can solve that problem in your encryption scheme, the code changes in CAS will be trivial by comparison and something you ought to be able to handle on your own. M [1] http://en.wikipedia.org/wiki/Key_management -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] client side password encryption
How do we enable client side password encryption and then server side decryption in CAS. Any suggestions/hint will be really helpful. Can you clarify what you mean by password encryption? Encryption of credentials used in configuration files (i.e. ldap/database password)? M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] client side password encryption
I think he refers to the client side (the browser) encrypting the password, shipping that through to the server, and the server decrypting it. It's hard to imagine what additional security that would provide in addition to SSL/TLS transport security that encrypts the entire form payload including the password. The security characteristics are the same: the client has access to the cleartext password and the server has access to the decryption key to decrypt the ciphertext. You add some new problems like browser support for encryption and symmetric key exchange/management. I would strongly advise against it. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Form+X509 mixed config and user selection
Is it possible to drive the user to a page in order to choose form or X509 auth instead of trying to force X509 in a very first step? Yes. We do a variant of this to provide a high-security login form that posts to an alternate port on submit; the alt port is configured for optional client SSL. It's just a matter of adding views and tweaking the login flow, which isn't hard but I would call it advanced configuration. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] This is embarassing
Can anyone give me one good reason to keep that check box? I'm pretty sure you've given us a good executive summary for removing it. :) In any case, while your experience sounds particularly bad, we've had some headaches supporting extended flows while maintaining proper function of the warn feature. Ticket expiration like you noted is the main concern. It's probably best to simply remove it; nobody here uses it either. Arguably nobody _any_where. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0: LDAP Attribute Repository - I think I have it working - How to verify? - Someone PLEASE respond
Nope, all that does is cause the attributes to have empty values in them: Ok, I did a little code review and have a suggestion. The trigger to resolve attributes from a principal resolver is the definition of a PrincipalResolver component in the value side of PolicyBasedAuthenticationManager#handlerResolverMap. So keep your attributeRepository bean but don't wire it into your PolicyBasedAuthenticationManager bean. Let me know whether that fixes your problem. Best, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] How to remove TARGET parameter
I always get the TARGET parameter in the url until the user authenticates. How can I remove this TARGET parameter? TARGET == ticket for the SAML feature in CAS, so it's naturally present until you authenticate. That's to say you can't and shouldn't remove it. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0: LDAP Attribute Repository - I think I have it working - How to verify? - Someone PLEASE respond
I tried dropping back to just a stub attributeRepository bean: bean id=attributeRepository class=org.jasig.services.persondir.support.StubPersonAttributeDao p:backingMap-ref=attrRepoBackingMap / util:map id=attrRepoBackingMap entry key=uid value=user / entry key=mail value=email / entry key=cn value=displayName / entry key=eduPersonPrincipalName value=eduPersonPrincipalName / /util:map Try empty values and see what happens, e.g.: entry key=uid value= / Let me know whether or not that changes the behavior. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Java CAS Client 3.2.2 ?
https://github.com/Jasig/java-cas-client/pull/81 Wrong base branch. Let's try again: https://github.com/Jasig/java-cas-client/pull/82 M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4.0.0: LDAP Attribute Repository - I think I have it working - How to verify? - Someone PLEASE respond
In short, is there some way to dump the
principal after authentication, or some other way to tell if the
attributes have been properly stored.
PolicyBasedAuthenticationManager logs the resolved principal at DEBUG:
logger.info(Authenticated {} with credentials {}., principal,
Arrays.asList(credentials));
logger.debug(Attribute map for {}: {}, principal.getId(),
principal.getAttributes());
Turning up org.jasig.cas.authentication to DEBUG would print out the
information you need to definitively show whether the attributes you
expect are in the principal.
This is the definition of the primaryPrincipalResolver that seems to
finally be working:
!--
| Resolves a principal from a credential using an attribute
repository that is configured to resolve
| against a deployer-specific store (e.g. LDAP).
--
bean id=primaryPrincipalResolver
class=org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver
property name=attributeRepository ref=attributeRepository /
/bean
While I imagine that it does work, it's not efficient since you're
effectively doing attribute resolution twice. The handler can resolve
attributes on the same connection as that used for authentication;
with PersonDirectoryPrincipalResolver, you're opening a new connection
to do it again. The wrinkle is that you MUST define an
attributeRepository bean for use by other system components, but you
should probably use a StubPersonAttributeDao [1] bean that simply has
the attribute mapping.
M
[1]
http://developer.jasig.org/projects/person-directory/1.1.1/apidocs/org/jasig/services/persondir/support/StubPersonAttributeDao.html
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Java CAS Client 3.2.2 ?
MA I built one-off patches [of Java CAS Client 3.2 and 3.1] for my institution, but we will consider providing official patches for those lines if there is interest. I'm happy to provide patches, but I need someone to step up to do the release process. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] x509 authentication Failing
bean id=x509Handler class=org.jasig.cas.adaptors.x509.authentication.handler.support.X509CredentialsAuthenticationHandler property name=trustedIssuerDnPattern value=CN=*/ property name=maxPathLength value=3 / property name=checkKeyUsage value=false / property name=requireKeyUsage value=false / /bean ... Which if i understand correctly, will authenticate ANY (*) issuer DN You're missing an important detail that I would like to clarify. While your trustedIssuerDnPattern pattern is incorrect as Sean noted, the above filter acts only _after_ the container completes the PKIX trust check that is part of the SSL/TLS handshake. That's really where issuer enforcement happens; trustedIssuerDnPattern is a supplemental check. There is no way to allow ANY certificate into CAS without implementing a custom component that plugs into the servlet container SSL machinery; see [1] for an example. While I doubt you really want to allow any issuer in practice, I did want to clarify the security policy implementation. M [1] https://github.com/Unicon/shibboleth-tomcat-dta-ssl/ -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172
Yes, it would ease patching. I'm finding getting a uPortal 4.0 release squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be substantially unpleasant. Ok. Here's the catch. Some of the integration modules, cas-client-integration-atlassian comes to mind, have dependencies in third-party repositories that are defunct. That makes a complete project build sufficiently difficult if not impossible that the return on investment is not justifiable. I would imagine that most folks need cas-client-core exclusively, and I would recommend we focus our efforts on patches for that module alone. Additionally, that's the only module affected by patching. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Ticket Validation Succeeds Against Services With Different Protocols
This apparently happens because we don't believe we have access to the TARGET to validate: https://github.com/Jasig/cas/blob/master/cas-server-support-saml/src/main/java/org/jasig/cas/support/saml/authentication/principal/SamlService.java#L96 Thanks for investigating. Agree that appears wrong because as you said we _do_ have TARGET on validate. Can you file an issue? Thanks, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172
However, for #2, I have a hard time seeing how the server would allow you to request a ticket for A and then use it for B. Both attacks are really the same with different origins. While it's not appropriate to provide an attack sequence here, I encourage you to continue thinking about this with URL encoding in mind. The client is guilty of accepting unvalidated input, and the ticket validation request can be made to look legitimate to the CAS sever when in fact it violates the service/ticket pairing. Is the idea that the client is *really* requesting a ticket for B in the first place? No. It's tricking B to send a ticket validation request for A. The prerequisite is a legitimate ticket for A. The trick is to make B use A's service URL with the legitimate ticket for A. That would not be possible if the client URL encoded request parameters properly. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
[cas-user] CAS Client Security Vulnerability CVE-2014-4172
A critical security vulnerability has been discovered in several Jasig CAS clients that allows URL parameter injection due to improper URL encoding at the back-channel ticket validation step of the CAS protocol. The following CVE number has been assigned to track this vulnerability: CVE-2014-4172 Affected Software Jasig Java CAS Client Vulnerable versions: 3.3.2 Fix version: 3.3.2, http://search.maven.org/#browse%7C1586013685 .NET CAS Client Vulnerable versions: 1.0.2 Fix version: 1.0.2, http://downloads.jasig.org/cas-clients/dotnet/dotnet-client-1.0.2-bin.zip phpCAS Vulnerable versions: 1.3.3 Fix version: 1.3.3, http://downloads.jasig.org/cas-clients/php/1.3.3/CAS-1.3.3.tgz There may be other CAS clients that are vulnerable. Impact The nature of the vulnerability allows malicious remote (network) agents to craft attack URLs that bypass security constraints of the CAS protocol. The following attack scenarios are known and have been demonstrated: 1. A malicious service that can obtain a valid ticket can use it to access another service in violation of the CAS protocol requirement that a ticket issued for a service can only be used to access the service for which the ticket was granted. This type of access amounts to an illicit proxy: the attacker is proxying authentication for the target. 2. A malicious user can request a ticket for service A and use it to access service B with the access privileges of A. Attacks like scenario 1 could result in unauthorized data disclosure, while scenario 2 could result in privilege escalation. Other attack scenarios may be possible. Remediation Upgrade affected CAS clients as soon as possible. Consider mitigation if upgrading is not possible. Mitigation The CAS Service Management facility [1], which is enabled by default, can be used to restrict services that are permitted to use CAS (i.e. allowed to request tickets). Whitelisting trusted services can reduce the scope of attacks like scenario 1 above. The following servlet filter may provide additional defense at the CAS server against some forms of this attack: https://github.com/Jasig/cas-server-security-filter/tree/cas-server-security-filter-1.0.0 Best, Marvin Addison CAS Developer [1] http://jasig.github.io/cas/4.0.0/installation/Service-Management.html -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172
I actually stumbled across similar behavior last week. In my case the CAS Server issued a ticket for service: https://mydomain.com/path And the successfully validated the ticket against service: http://mydomain.com/path That's unlikely related to the client security vulnerability. We would need logs from the server and possibly client(s) to say for certain. I would appreciate your starting a separate thread to discuss further. Thanks, M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172
Does this affect ALL versions of the Java client prior to 3.3.2? I did code review of the latest 3.2 and 3.1 versions and they were both vulnerable. I built one-off patches for my institution, but we will consider providing official patches for those lines if there is interest. Also, is there a way to get the 3.3.2 jar without having to do a Maven build? Latest on the downloads site is 3.2.x. I noticed there's no download bundle as well. I imagine Scott simply hasn't gotten to it yet, but I'm sure simply mentioning it here will make it magically appear :) M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Ticket Validation Succeeds Against Services With Different Protocols
2014-08-11 14:48:53,829 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket [ST-1-ZVJ45whjWQCXrJQVHVmd-abbott] for service [https://ckillingsworth2.missouristate.edu/testcasapp] for user [chk790] Can you post the corresponding log entry that reads something like the following: Successfully validated ticket [ST-1-ZVJ45whjWQCXrJQVHVmd-abbott]. You may have bigger problems if you do not have such a line. Chad noted that this is a load-balanced service, so the validation may have happened on another node since the ticket request and validation have distinct sources. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS integration with Shibboleth IDP
We have our Shibboleth IDP using CAS as the only login handler resulting in CAS being the manager of the SSO session and Shibboleth being simply a pasthrough for SAML. Since the Shibboleth IDP does not maintain an SSO session it should redirect to CAS for each auth request to get a new Service Ticket. While your expectation is correct, I have the feeling you want to prompt the user for credentials on every federated service access request. Unfortunately that is not possible. If you disable the Shib Previous Session authn handler [1], which is the meaning I take from Shibboleth IDP does not maintain an SSO session, you will still incur exactly one CAS authentication. The reason is that for any browser-mediated SAML profile, browser cookies come into play. Here's the flow: 1. User browses to spA.example.org 2. User selects home institution and is redirected to idp.bar.edu 3. IdP engages CAS authentication provider, which triggers redirect to CAS, cas.bar.edu 4. No CASTGC cookie is present, so user is prompted to login to CAS 5. User authenticates to CAS and is redirected to idp.bar.edu with ticket 6. IdP validates ticket and authn engine completes successfully 7. IdP redirects to spA.example.org with SAML response 8. ... time passes ... 9. User browses to spB.example.org 10. IdP engages CAS authentication provider, which triggers redirect to CAS, cas.bar.edu 10. CASTGC cookie is present so CAS issues ticket to IdP via redirect 11. Steps 6-7 as before So while a new ST is granted for every federated service access request, only one login occurs, the one that initiated the CAS SSO session. Thus you will see exactly one CAS login for a number of federated service access requests that happens during the lifetime of the CAS SSO session. While the renew CAS protocol parameter could theoretically help you here, the SP would have to set that flag, which is outside of your control. I hope that explains the behavior you are seeing. [1] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAuthPreviousSession M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS integration with Shibboleth IDP
I only want the IDP to get a new ST at each auth, which is what is not happening. You should provide some evidence to that effect. A browser request trace would show the important interactions. I think the key here - pointed out by Tom - is that the CAS client is maintaining a session similar to an SP. The only CAS client in your scenario is the IdP. If you have disabled the SSO support in the IdP along the lines of the wiki page I cited, then you ought to get an ST for every relying party that interacts with the IdP. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] password manager
Does anyone know if there are instructions for integrating the password manager into an existing cas install? Not sure what you're asking about. CAS 4 ships with support for password expiration workflows, but has no facilities for password management. In other words it can help inform the user about impending password expiration and password expiration conditions, but it can't do anything about it other than possibly redirecting a user somewhere else. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Cas 4.0.0, AD and memcached
sory more information about the error : 2014-07-30 14:39:55,547 ERROR [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed fetching TGT-2-HayENMIZIswzmGw3kYaNChMHjpUQPcOjKTmdM6TBh4Tb25qfWz-cas2 java.lang.RuntimeException: Exception waiting for value You specified the following for your memcached hosts: memcached.servers=memcacheSRV:11211 From your CAS host, execute the following command in a shell/terminal: nc -w3 memcacheSRV 11211 (On Windows you'll need to install netcat; the command is netcat on Windows.) Once connected type the following command: stats If you get an output of memcached statistics, then that rules out connection problems. If you have trouble connecting, which I would expect based on the error above, then you need to work with your networking folks to get connectivity. Using netcat is a quick troubleshooting method. Once you get memcached statistics with netcat, then return to CAS M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Cas 4.0.0, AD and memcached
but i got connectivity between my cas srv and my memcached serveur . Good. Turn up logging for the following category to debug: org.jasig.cas.ticket.registry Repeat your authentication attempt and post the resulting logs. If you don't see additional details, there is a problem with your logging configuration and you should troubleshoot that until you do see additional information. We must have more info to troubleshoot further. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Cas 4.0.0, AD and memcached
Ah, the root cause: Caused by: com.esotericsoftware.kryo.SerializationException: Unable to deserialize object of type: org.jasig.cas.ticket.TicketGrantingTicketImpl This may be a bug Caused by: com.esotericsoftware.kryo.SerializationException: Unable to deserialize object of type: org.jasig.cas.authentication.HandlerResult Please file an issue at https://github.com/Jasig/cas/issues where you include the full stack trace above and attach your deployerConfigContext.xml and ticketRegistry.xml files. In the meantime, you should be able to work around the error by using the default serializing transcoder. Just remove the following from your ticketRegistry.xml: p:transcoder-ref=kryoTranscoder And comment out or remove the kryoTranscoder bean. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Using SHA512
I'll look at the documentation again to try and work out the best/simplest approach. Can you briefly describe how you store the salt in your database? There's a quasi-standard for LDAP directories, SSHA, but nothing equivalent that I'm aware of in the database world. The challenge for the CAS project will be shipping a component that has the right configuration knobs, but we don't have good use cases from which to design those knobs at present. Your input will help in that regard. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS SSO solutions, and Microsoft SharePoint
Are those doing this generally taking CAS SSO, fronting it with a Shib IdP, then integrating with ADFS as a relying-party, that SharePoint uses for authentication ? We considered this path but aborted. In short, we needed close collaboration with the Microsoft folks at our institution and couldn't achieve it. It's also insanely complex. Federations are complex in themselves; inter-federation trusts are approaching insanity. Lots of folks make it work, but we felt it was overly complex for the relatively narrow use case of supporting CAS-Sharepoint integration. We're about to take such a path here at UVic, and I'm in the process of gathering community-thoughts for this journey. I believe you'll be in good company with that approach. We are attempting a direct WS-Federation integration with CAS and have some promising results in a preliminary RD experiment. I should note that it's technically different than the EWU approach that Scott cited previously. I'm fairly ignorant of the Sharepoint side, but I believe our approach amounts to hosting the WSFed components as a Sharepoint module that wraps the .NET CAS client. Development is still ongoing, but I can share further details as we progress if anyone is interested. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS display previous authentication time.
what is the correct way to display the last authentication time to the user before it is updated in LDAP? Custom Spring Webflow action that executes after authentication success. For example, replace sendTicketGrantingTicket action in the following state with your custom action: action-state id=realSubmit evaluate expression=authenticationViaFormAction.submit(flowRequestContext, flowScope.credential, messageContext) / transition on=warn to=warn / transition on=success to=sendTicketGrantingTicket / transition on=successWithWarnings to=showMessages / transition on=authenticationFailure to=handleAuthenticationFailure / transition on=error to=generateLoginTicket / /action-state Note you would need an additional state definition for your custom action that transitions to sendTicketGrantingTicket on success. Your custom state would be a view state, which requires a little more configuration to get going, but there are existing view states you could use as a template. We have done extensive customizations of this sort (password expiration warnings, self-service password reset configuration, etc) in this manner. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Using load balancer
Has anyone had 2 CAS servers with a load balancer? We are looking for a 24/7 solution and also for our DR plan. We have been running multiple servers in active-active mode for years now. I'm also aware of folks using active-failover setups with specialized LB hardware to do some pretty impressive HA setups. In any case the following CAS 4 documentation provides some thoughtful discussion on HA CAS setups: http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS 4 LPPE Configuration
My colleague, the ldaptive lead developer, mentioned that the error string returned from AD looks a little odd: message=javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 775, v1772\00], controls=null] What version of Windows Server are you running? We'll need to do some code review and testing on our side and follow up. Note it's a holiday weekend in the US. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] infinite loop just started on Peopleadmin after F5 update to 15.1
we did apply an update to our F5 load balancer on 6/15, bringing it up to 15.1. Redirect loops are commonly caused by SSL handshake failures that are handled poorly in the client. Did a cert change as part of the upgrade? You'll have more luck troubleshooting the problem at the client (PeopleAdmin) than the server since the client is the component responsible for the redirect to get you to CAS. Have PA turn up their logs and review carefully. Feel free to post excerpts and we'll try to help you troubleshoot. Has anyone else run into any weirdness like this that's using an F5? Doubtful the firmware update alone caused the problem, but maybe there were some configuration changes, including certs, that happened concurrently that are to blame. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] infinite loop just started on Peopleadmin after F5 update to 15.1
Thanks for the pointers. The issue is that the PeopleAdmin CAS client attempts to handshake using SSLv3 Shame on them. TSLv1, which has its own issues, has been recommended over SSLv3 for several years. I’m attempting to get them to update their side, but, I’m not holding my breath on that. I'd appreciate your following up on list if you get a response either way. We support SSLv3 but prefer TLSv1, but I applaud vendors like F5 shipping products with secure defaults. Too bad it's breaking enterprise services. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Need to clear browser cookies in order to login
I’ve beefed up my servlet session timeout to 7200 (... 5 full days). That amount of beef may lead to coronary problems. when they submit the login form, the form just resets and clears the username/password field instead of authenticating them and redirecting. Thoughts? The behavior you have cited is by design under an expired session condition: when a user posts credentials to an expired flow (backed by the session), a new flow is created and the user ends back up at the initial flow state which is an empty login form. In most cases simply entering credentials and posting them allows login to proceed. I understand you to say that an empty login form is repeatedly displayed on every attempt to post credentials; is that correct? In any case there's some evidence the servlet session is expired despite your extreme timeout. I should note that your session timeouts are well beyond anything we might encounter in a test environment. The default on Tomcat is 30 minutes; we have gone as high as 4 hours. 5 days is arguably ridiculous. What problem are you trying to solve with such extreme session timeouts? I'm hopeful treating the root problem instead of the symptoms may be more fruitful. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] OutOfMemoryException with long timeouts?
I set the web.xml session-timeout to -1 (infinite)... This morning our CAS instance was down due to an OutOfMemoryException (OOME) OOM would be the expected behavior for setting an infinite session timeout. You have effectively instructed the servlet container to never reclaim memory for abandoned sessions, which would be expected to produce OOM after a period of time that is a function of authentications/sec and memory capacity. I’m wondering if leaving sessions alive too long is exposing a memory leak somewhere in CAS (I’m on 3.5.2.1)? You haven't uncovered a memory leak, you have produced one by fairly drastic choice of configuration. There is simply no use case for infinite session timeouts. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Off-Site Hosting
We are currently looking to host our CAS server off-site Does anyone have any suggestions for hosting providers? I encourage you to check out http://www.casinthecloud.com/. I don't have any experience with the service, but the creator is a trusted community member. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Service Registry in database
I think the underlying problem in the code is that @Transaction annotations were placed at the wrong layer, on the methods in class CentralAuthenticationServiceImpl. +1 Your analysis and solution are probably the best evidence we have for that claim. I recall having made a similar suggestion in the past, but I didn't have a sound argument at the time. I believe your problem and solution provide the evidence we need to move forward with a fix in the next release of CAS. I would appreciate your filing a Jira issue to make the change you suggested and citing this thread as a reference. Thanks for your persistence working through this issue and sharing the result. Hopefully it will lead to a fix for this long-standing issue. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Service Registry in database
We put them on CASImpl because technically that is where the transaction would occur (a single method on that class could call multiple ticketregistry methods) Correct, but clearly that approach has some undesirable side effects. The only registry that would benefit from @Transactional on the CASImpl methods is JPATicketRegistry; all other backends are not transactional across multiple calls if they have transactional support at all. My opinion is that TicketRegistry has outlived its usefulness. I believe we would be better served by a generic StorageService facility (get/put/delete) that has @Transactional on its methods as needed for the JPA implementation. With a careful design of the semantics of get/put I'm confident we could provide secure ticket storage without the side effects that Andrew reported. Additionally, this approach would naturally isolate dependencies into technology-specific modules (JPA, Ehcache, memcached, LDAP) and hopefully reduce the number of components. In any case it's probably not as easy as simply dropping @Transactional on CASImpl for the reasons you cited, but with some deeper changes to our storage subsystem I believe we can have a win/win. I think a Jira issue citing the problem and solution Andrew noted would justify further research and development work in that direction. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CAS Clustering: Do I need to cluster Tomcat too?
the recommended architecture at http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html seems to indicate that session replication is not necessary That's correct. Unless you have some very strict and ambitious requirements for your HA solution, session replication is not necessary. A session effectively starts when the user shows up to the login screen, and ends upon successful authentication, which is sufficiently brief that any failure during that time frame is handled fairly gracefully by the user simply trying again. is this specific only to v4.0? Same analysis applies to every CAS version that uses Spring Webflow, which is 3.x onward. What's being stored in the Tomcat session Webflow conversation state is backed by session storage under normal circumstances. See [1] if you want an alternative. M [1] https://github.com/serac/spring-webflow-client-repo -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] LDAP MySQL Replication Best Practice Recommendations
I am looking for recommendations from the CAS community on the best practices you have found for LDAP and MySQL redundancy. The CAS4 documentation has a thoughtful section on high availability that should be your starting point: http://jasig.github.io/cas/4.0.0/planning/High-Availability-Guide.html I have no experience with database clusters, but substantial experience with HA LDAP infrastructure. If LDAP is your authentication store, I would strongly recommend a master-slave topology where the master may or may not be among the hosts that handle CAS authentication. You really SHOULD have a hardware load balancer in front of the nodes. With CAS4 there is a reasonable facility to connect to multiple LDAP hosts in a fairly performant way, but load balanced pools with a single virtual address are preferable. DNS round-robin is totally unsuitable for HA for reasons discussed in the document above. I believe many of the HA concerns around LDAP are applicable to a HA database infrastructure. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] Service Registry in database
The stack trace indicates that some Spring AOP proxy is intercepting the I see that createTicketGrantingTicket() has an @Transactional annotation applied to it. Could this be causing the spurious calls to autocommit and commit? Yes, I think that's it. I would recommend trying to restrict the scope of Spring AOP transactional proxies to just the service registry. I've never seen that done, but aop:aspectj-autoproxy takes a subelement, include [1] that is a regex where you can specify the scope of included components. I can imagine a regex that would include ServiceRegistryDao but exclude CentralAuthetnicationServiceImpl. Try that and report back. M [1] http://www.springframework.org/schema/aop/spring-aop-3.0.xsd -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] CASTGC Cookie?
1. What is the CASTGC cookie? What role does it play when logging in? 2. When is the CASTGC cookie generated? 3. What happens if the CASTGC cookie isn't present when the user signs in? I believe the following section of the CAS protocol document answers all the above: http://www.jasig.org/cas/protocol#ticket-granting-cookie M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] cas 4.0.0, LdapAuthenticationHandler and objectGuid
1) I have 2 authentication handlers that are used concurrently, one which uses a DB query and the other a LDAP query... Is this an appropriate use of the postAuthenticate method, or am I twisting this extensibility point in a way it isn’t intended? Sounds like a creative use though I wouldn't call it wrong or twisted. The recommended way to do what you're doing is by leveraging the PrincipalResolver components. Resolvers naturally execute after authentication using the credential as input and produce a principal; in your case you would query AD using the objectGuid in the database record as a search filter. You can map a resolver to an authentication handler so that a particular one fires only after the desired handler succeeds. I can provide more guidance on configuration if you're interested in that approach. Again, there's nothing wrong with your approach per se, it just short circuits some of the natural authentication pipeline that could probably handle it with OOB components. 2) I noticed objectGuid from Active Directory was being garbled... I dug through the ldaptive code and it seems like I need to set the objectGuid entry as binary. Apparently there is an ObjectGuidHandler class which handles this already. Does this seem like a reasonable change, or is this problem better handled in a different way? You did the right thing. In fact, I'm impressed by your sleuthing to figure out that you needed ObjectGuidHandler to get the proper attribute handling. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] cas 4.0.0, LdapAuthenticationHandler and objectGuid
I tried to use a PrincipalResolver originally, but it seemed inefficient.
Not the first time someone has made that argument.
ldap.authn.searchFilter=(|(sAMAccountName={user})(proxyAddresses=smtp:{user}))
so I can't make too many assumptions based on their credentials. This means
I would have to effectively redo the same search just done by the
AuthenticationHandler to get the ObjectGuid that it already had.
Inefficiencies of this sort drove the creation of principal resolution
support directly in the AuthenticationHandler in CAS 4. At present
it's an either-or proposition: if the AH produces a principal, the
AuthenticationManager skips principal resolution in whatever
PrincipalResolver is configured for that handler. Your use case makes
me think we should support some configuration that makes that behavior
optional in order to support chaining resolvers, which I can admit is
a potentially powerful facility.
Am I missing something in my PrincipalResolver that would allow me to take
advantage of the work already done by the authentication handler?
Only if we do some further work to allow resolver chaining. That would
mean tweaking the contract of PrincipalResolver to accept either a
Credential or a Principal, but that sounds reasonable at first glance.
In any case I'm open to considering further in the context of an
enhancement targeting 4.1. Please file a Jira issue if that sounds
good to you. Thanks for sharing your use case.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] AuthenticationHandler / PrincipalResolver
So when I got the point of 'enriching' the principal with some
additional metadata I was surprised to see that that resolver got the
same credentials as the authentication handler.
That's the contract: given an authenticated credential, determine a principal.
I have to re-run the code that I have in my authentication handler
again right?
Not necessarily. You'd have to say more about the details of the
queries you're executing and the back end data store(s).
Due to the fact that the underlying data is rather
polluted I can even have multiple accounts with the same email address
where only the password differentiates
In the common CAS protocol case, only the principal ID is conveyed to
clients. How will clients distinguish between two users named jsmith
that map to different people? The metadata you mentioned? Note you
will have to release that metadata as attributes that the client can
consume to disambiguate. This is a vital concern that you must address
before you proceed.
Relevant code in the AuthenticationManager:
---
final HandlerResult result = handler.authenticate(credential);
...
resolver = this.handlerResolverMap.get(handler);
if (resolver == null) {
principal = result.getPrincipal();
That assignment is new and supports principals resolved directly from
the authentication handler data store. In many cases, if not the
common case, the principal is just another attribute in the same
record as the username or other user primary ID. In that case you
would not configure a resolver and you would fall into this block.
logger.debug(
No resolver configured for {}. Falling back to handler
principal {},
handler.getName(),
principal);
} else {
principal = resolvePrincipal(handler.getName(), resolver, credential);
This implements the PrincipalResolver contract: given the
authenticated credential, determine a principal.
Basically I was expecting the second to last line to use
'result.getPrincipal()' instead of just 'credential'.
Hopefully my comments above shed some light.
The lookup of the principal in the authenticationhandler is also
rather slow :-|.
Due to your systems or our components?
I see that if I don't set a resolver I can enrich the
principal in the authentication handler myself and eventually that
principle will be used, but it doesn't seem 'correct'.
That behavior is by design as I mentioned above. If you're querying
the same data store for the principal as that used to authenticate,
you may be able to simply enhance an out-of-box AuthenticationHandler
to suit your needs. Mixing PrincipalResolver and AuthenticationHandler
at this point is primarily to support disparate identity stores; for
example Kerberos for authentication and LDAP for principal resolution.
M
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] TGT table not getting cleaned up
So, all our ticketRegistry.xml has in it is below. Should we just comment out everything under !-- Quartz --? Yes, upon setting up an external job to clean up orphaned tickets in a more efficient manner. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] TGT table not getting cleaned up
2014-04-17 19:51:52,279 ERROR [org.hibernate.util.JDBCExceptionReporter] - DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.50.152 2014-04-17 19:51:52,279 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] - Could not synchronize database state with sessionorg.hibernate.exception.LockAcquisitionException: could not delete: [org.jasig.cas.ticket.TicketGrantingTicketImpl#TGT-2284-diTwnt9x0sYdKYLoXcQdWBYRb1ZTdumpbjyKK3wnHFnepuVS50-cas_25] That error is a sign of a concurrency/locking situation. Concurrency happens; deadlocks happen; it's just a matter of usage patterns and database platform that determines the extent. I have no experience with DB2 but it may simply not handle concurrency as well as some others. Oracle does well, Microsoft SQL Server does poorly, PostgreSQL only marginally better; others can speak up about MySQL/MariaDB/whatever it's called today. I'd recommend running a cron job with a query like what I provided earlier in the thread (straight delete) and remove the Java/Quartz job and be done with it. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] TGT table not getting cleaned up
On Tue, Apr 22, 2014 at 9:10 AM, Jason Roscoe jros...@riteaid.com wrote: How would I go about removing the Java/Quartz job? Please review the first Spring configuration section of the following wiki page: Jason Roscoe | Rite Aid | T: (717) 761-2633 x5581| jros...@riteaid.com -Original Message- From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: Tuesday, April 22, 2014 9:09 AM To: cas-user@lists.jasig.org Subject: Re: [cas-user] TGT table not getting cleaned up 2014-04-17 19:51:52,279 ERROR [org.hibernate.util.JDBCExceptionReporter] - DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68, DRIVER=3.50.152 2014-04-17 19:51:52,279 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] - Could not synchronize database state with sessionorg.hibernate.exception.LockAcquisitionException: could not delete: [org.jasig.cas.ticket.TicketGrantingTicketImpl#TGT-2284-diTwnt9x0sYdKY LoXcQdWBYRb1ZTdumpbjyKK3wnHFnepuVS50-cas_25] That error is a sign of a concurrency/locking situation. Concurrency happens; deadlocks happen; it's just a matter of usage patterns and database platform that determines the extent. I have no experience with DB2 but it may simply not handle concurrency as well as some others. Oracle does well, Microsoft SQL Server does poorly, PostgreSQL only marginally better; others can speak up about MySQL/MariaDB/whatever it's called today. I'd recommend running a cron job with a query like what I provided earlier in the thread (straight delete) and remove the Java/Quartz job and be done with it. M -- You are currently subscribed to cas-user@lists.jasig.org as: jros...@riteaid.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: marvin.addi...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] TGT table not getting cleaned up
How would I go about removing the Java/Quartz job? Please review the first Spring configuration example on the following page: https://wiki.jasig.org/display/CASUM/JpaTicketRegistry The comments in the sample are fairly detailed and the cleaner job is fairly obvious. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Re: [cas-user] TGT table not getting cleaned up
DELETE FROM TICKETGRANTINGTICKET WHERE ID=? The ticket cleanup task is known to be poorly optimized. Note that it's issuing a per-ticket delete _after_ loading all tickets into memory. That's likely unworkable for the number of tickets you mentioned (4M). If you're having trouble simply schedule a job to delete any tickets idle for more than, say, 24 hours: DELETE FROM TICKETGRANTINGTICKET WHERE LAST_TIME_USED 24_hours_ago; (The way you compute 24 hours ago is a platform-specific detail.) You'd choose a more conservative TTL if you're using remember me. Is the TICKETGRANTINGTICKET_ID supposed to be null? I’m thinking it should not. It's probably more likely to be null than not unless you do a lot of proxying. That's a foreign key used to create a ticket graph; for example CAS proxy support. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
